[05:46] <mborzecki> morning
[06:07] <mardy> mborzecki: hi!
[06:14] <mardy> mborzecki: about what you wrote yesterday about snap-confine and capabilities, you are absolutely right, we'll need CAP_SYS_ADMIN and some other capabilities; but we don't need them permanently, we can just add them to the "permitted" set, and then make the effective in those same places where we asked to become root before
[06:15] <mardy> so, it should work like before, just that now we won't have the full capability set when we are privileged, but only a subset of it; and we'll run under the right user
[06:16] <mardy> of course we want to talk to Samuele and security before making such changes, and we should also understand how important this is
[06:16] <mardy> mborzecki: but it sounds like it's a problem for NFS too: https://bugs.launchpad.net/snapd/+bug/1973321
[06:16] <mup> Bug #1973321: snaps dont't start when current working directory is on sshfs <snapd:New> <https://launchpad.net/bugs/1973321>
[06:19] <mborzecki> mardy: nfs probably squashes the root
[06:20] <mardy> mborzecki: oh, I see, and it looks like it's the default behaviour
[06:23] <mborzecki> mardy: my main worry about caps is that once you drop CAP_SYS_ADMIN there would be no way to get it back? there's probably a way to flip between effective/permitted caps somehow
[06:23] <mborzecki> mardy: and then there are some paths that s-c creates which need to be created by root, but I suppose those are under /var/lib/snapd any and could be created early
[06:24] <mborzecki> mardy: fwiw i see that s-c already links libcap, so we could use the wrappers it provides
[06:43] <mardy> mborzecki: yes, AFAIK you can flip, as long you don't remove the capability from the permitted set. For creating files as root, CAP_CHOWN should help
[06:47] <mborzecki> mardy: things would probably be easier if we ever went forward with the plan to have caps set on the s-c file rather than setuid
[06:48] <mborzecki> though things require cap_sys_admin so meh 😕
[06:52] <mborzecki> acutlly, let me try something, i'll drop setuid from s-c and just set caps, wonder if/how it will break
[07:02] <pstolowski> morning
[07:39] <mborzecki> mardy: hmm some fun: https://paste.ubuntu.com/p/r64XJqcBMR/
[07:39] <mborzecki> fails on chowning the private temp with a sticky bit for some reason
[07:40] <mborzecki> mardy: this is as far as it gets https://paste.ubuntu.com/p/XZtsFws2QW/
[07:56] <diddledani> mborzecki: might be because it's tmpfs? "On some filesystems, only the superuser can set the sticky bit, which may have a special meaning.  For the sticky bit, and for set-user-ID and set-group-ID bits on directories, see inode(7)." (from chmod(2) manpage)
[07:57] <diddledani> I can't find any specific capability for chmod affecting just the sticky bit
[07:57] <mborzecki> diddledani: afaiu it's either s_fsetid or s_fowner
[07:57] <mborzecki> s/s_/cap_/
[07:57] <mborzecki> CAP_FSETID or CAP_FOWNER
[08:00] <mborzecki> mardy: all of the changes i have: https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/s-c-with-caps
[08:00] <mborzecki> mardy: i suspect that since it's not really changing the uid/gid of the running process, we should not stumble upon the problems with fuse/nfs
[08:32] <diddledani> looks like CAP_FOWNER should be sufficient, so I donno
[08:34] <mup> Issue core20#94 closed: fix pi4 names for wlan0 and eth0 <Created by xnox> <Closed by mvo5> <https://github.com/snapcore/core20/issues/94>
[09:56] <mup> PR snapd#11774 closed: i/b/mount_control: add an optional "/" to the mount target rule <Created by mardy> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/11774>
[10:25] <mup> PR pc-amd64-gadget#61 opened: Unbreak core22 gadget <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/61>
[10:36] <mardy> mborzecki: nice! But I think we still need the setuid bit, in my tests at least I could not make the sc_reassociate_with_pid1_mount_ns() function work without it
[10:37] <mardy> mborzecki: setns() has some very strict requirements
[10:37] <mborzecki> mardy: you need CAP_SYS_PTRACE for this
[10:37] <mborzecki> ah w8
[10:37] <mborzecki> or maybe not
[10:38] <mborzecki> > Changing  the  mount  namespace  requires that the caller possess both CAP_SYS_CHROOT and CAP_SYS_ADMIN capabilities in its own user namespace and CAP_SYS_ADMIN in the user               namespace that owns the target mount namespace.
[10:38] <mborzecki> once we assemble all the caps, it's actually as if it's running as root really 😕 just the uid isnt 0
[10:41] <mardy> mborzecki: I'm now fighting with something different:
[10:41] <mardy> DEBUG: current caps: = cap_chown,cap_dac_override,cap_dac_read_search,cap_sys_chroot,cap_sys_admin+p
[10:41] <mardy> DEBUG: acquiring 1 effective capabilities
[10:41] <mardy> DEBUG: capability: 0
[10:41] <mardy> DEBUG: about to set caps: = cap_chown+ep cap_dac_override,cap_dac_read_search,cap_sys_chroot,cap_sys_admin+p
[10:41] <mardy> cannot set capabilities on process
[10:41] <mup> PR snapd#11734 closed: interfaces: network-manager: add AppArmor rule for configuring bridges <Created by IsaacJT> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11734>
[10:41] <mup> PR snapd#11777 closed: i/b/hardware-observe.go: add access to the thermal sysfs <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11777>
[10:41] <mup> PR snapd#11789 closed: interfaces: opengl: add rules for NXP i.MX GPU drivers <Created by IsaacJT> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11789>
[10:42] <mardy> mborzecki: this is running as an ordinary user. So, I have a few capabilities in the permitted set, including cap_chown
[10:42] <mardy> mborzecki: then I request to have cap_chown in the effective set, but cap_set_proc() fails
[10:42] <mborzecki> mardy: ah, so you're just dding effective ones as needed?
[10:42] <mardy> mborzecki: yes, that was my intention, but I cannot get it to work
[10:43] <mborzecki> mardy: maybe you need CAP_SETPCAP
[10:43] <mborzecki> in ep
[10:43] <mardy> mborzecki: initially, if our binary is setuid root, our set is cap_chown,cap_dac_override,cap_dac_read_search,cap_setgid,cap_setuid,cap_sys_chroot,cap_sys_ptrace,cap_sys_admin,cap_sys_resource+ep
[10:43] <mardy> mborzecki: according to the doc, I need it only if I want to change the inherited set
[10:45] <mardy> mborzecki: it even fails if I try to set the very same set that I get from cap_get_proc()...
[10:51] <mup> PR pc-amd64-gadget#61 closed: Unbreak core22 gadget <Created by xnox> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/61>
[10:51] <mardy> mborzecki: so, capget() + capset() work. cap_get_proc() also works, but cap_set_proc() always fails
[10:53] <mborzecki> mardy: ahve you tried on a smaller example maybe?
[10:55] <mborzecki> looking at the manpage, it's cap_get_proc(), manipulate the flags inside the returned caps, and then cap_set_proc()
[11:01] <mup> PR snapd#11713 closed: interfaces: allow access to the file locking for cryptosetup in the dm-crypt interface <Created by bugraaydogar> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11713>
[11:01] <mup> PR snapd#11720 closed: interfaces: fix opengl interface on RISC-V <Created by Saviq> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11720>
[11:02] <mardy> mborzecki: indeed, on a smaller test it works :-/
[11:08] <mardy> mborzecki: the LOL of the day :-) Find the error: if (cap_set_proc(caps) < 1) { die("cannot set capabilities on process"); } :-D
[11:24] <pstolowski> < 0 ?
[11:42] <mardy> indeed :-)
[12:37] <mborzecki> mardy: so, does it work with caps only now?
[12:52] <mardy> mborzecki: yes, but I did not try with filesystem caps: I'm still setuid root, then I drop the user, and set the caps as needed
[12:52] <mardy> mborzecki: I need to try with your approach (caps on the filesystem, no setuid bit)
[12:55] <mardy> mborzecki: anyway, touching the code I realize (or at least it appears to me to be so) that most of the calls to sc_set_effective_identity() which we now do, are not needed
[12:57] <mup> PR snapd#11778 closed: cmd/snap: replace existing code for 'snap model' to use shared code in clientutil (2/3) <Created by Meulengracht> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11778>
[13:02] <mborzecki> mardy: yeah, i commented out most of them in my branch
[13:02] <mborzecki> guess, it's enough to chown() after creating
[13:46] <mardy> mborzecki: what cap is needed to create the tmp dir as 01777?
[14:00] <mborzecki> mardy: ah, didn'tget it to work, https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/s-c-with-caps#diff-873235435b32bdec83fa69bddac35d88b80edbf85a28090b851c16065ea6a86bR195
[14:00] <mborzecki> i think that those caps should allow this, but they didn't
[14:02] <mborzecki> maybe it needs a chown to root or sth
[15:01] <mardy> mborzecki: it's probably cap_fowner or cap_fsetid, but for some reason I cannot set these caps. Even setting them on the filesystem does not help: the process won't have them
[15:02] <mardy> mborzecki: you also don't seem to have it, according to line 20 in your pastebin: https://paste.ubuntu.com/p/XZtsFws2QW/
[15:03] <mborzecki> mardy: do you still have a setuid binary?
[15:13] <mup> PR snapcraft#3742 opened: parts: copy kernel.yaml and gadget.yaml <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3742>
[15:16] <mardy> mborzecki: no, I removed it; but it does not seem to matter; even when setuid, calling cap_proc_get() returns many capabilities, but not these two (and many others are missing, too)
[15:16] <mardy> mborzecki: it would seem that there is a "bounding set" set
[15:18] <mardy> (except that there isn't, AFAICT)
[15:47] <mup> PR snapd#11794 opened: interfaces: add an allow-exec attribute to the removable-media interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/11794>
[15:48] <mup> PR snapd#11795 opened: cmd/snap/pack: make check-skeleton implicit <Created by xnox> <https://github.com/snapcore/snapd/pull/11795>
[15:49] <mardy> mborzecki: got the ambient capabilities to work; still no luck with the sticky bit
[16:03] <mup> PR snapd#11796 opened: daemon: move user add, remove operations to overlord device state <Created by kubiko> <https://github.com/snapcore/snapd/pull/11796>
[16:08] <mup> PR snapd#11797 opened: seed: add support to load auto import assertion <Created by kubiko> <https://github.com/snapcore/snapd/pull/11797>
[16:13] <mup> PR snapd#11791 closed: tests: fix the system-snap-refresh test <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/11791>
[17:36] <diddledani> yo, there are some missing ca-certificates in core20 - I think this is causing obs-studio to error out - specifically there are symlinks in /etc/ssl/certs that point to non-existent files in /usr/share/ca-certificates
[17:37] <diddledani> I believe core20 provides /etc/ssl/certs and /usr/share/ca-certificates?
[17:37] <diddledani> that is when core20 is the base snap for a particular snap - in this case obs-studio does use core20 as its base
[17:38] <diddledani> specifically these are missing but are mentioned in symlinks residing in /etc/ssl/certs https://www.irccloud.com/pastebin/1bPuobsg/
[18:33] <mup> PR snapd#11798 opened: asserts/info,mkversion.sh: capture max assertion formats in snapd/info <Created by pedronis> <https://github.com/snapcore/snapd/pull/11798>
[20:09] <mup> PR snapd#11793 closed: tests: fix auto-refresh-gating test forcing reset-failed before restart <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/11793>
[20:28] <mup> PR snapcraft#3742 closed: parts: copy kernel.yaml and gadget.yaml <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3742>
[21:38] <mup> PR snapcraft#3743 opened: pack: check skeleton <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3743>
[23:33] <mup> PR snapcraft#3743 closed: pack: check skeleton <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3743>
[23:33] <mup> PR snapcraft#3744 opened: cli: enable craft-store logging <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3744>