>
> Thanks, that's a useful data point. Do you think it is a practical concern
> for snaps if an Ubuntu rootfs uses fscaps? Is this an argument against
> allowing fscaps in Ubuntu, or should it just be a matter for snapcraft to
> warn/error about on creation, guiding users to using setuid instead?
>
> As a worked example: the core snap does ship /bin/ping, which is currently
> setuid-root in Ubuntu but would move to fscaps in this proposal. (The core
> snap does not include mtr-tiny.) What do you believe is the correct outcome
> here for /bin/ping in a future ubuntu core 20 snap?
Given that fine-grained fscaps are better than blanket setuids, I
expect core 20 to embrace them wholeheartedly.
However, getting there will involve the whole
snapcraft/snapd/review-tools/snapstore stacks for at least a little
bit of work.
We need to sit down and decide what shape that support is going to
take (basically: can everybody have xattrs & fscaps, or is it just
base snaps? any base snap, or only core? policy decisions, involving
security). I don't expect it to be controversial, unless we want to
enable a snapped application to use fscaps.
We need to do a bit of research _today_, because already 16.04 has
tools that rely on fscaps: this conversation has had me notice that
systemd-detect-virt, that we ship in core and use from snapd in a
couple of places (and in particular to check whether we need to use
squashfuse) is using caps instead of setuid, meaning that in core for
a regular user it probably won't work properly. So we'll need to look
into exactly how it's being used; I _think_ we're testing them as
root, and only expect to be using them as root, but we'll have to
chase it down.
We need to make sure the races that plagued us around execing setuids
aren't revived by fscaps. They shouldn't.
I think that's all.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
