[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