For now, yes. When we have uid/gid support in snapd, we can happily expand this to the users that the snap is allowed to use.
That doesn’t mean you have to rip out all the uid/gid code for layouts-- continue to use it for root:root. You could even leave the yaml exposed (but only allow root:root for now) if you don’t advertise it. I’ll leave that up to you (though, it seems possible the yaml might change when uid/gid support lands, so maybe it is best to not expose the yaml at this time).
So today was exceptionally fruitful for layouts. I discussed the feature extensively with @jdstrand and we agreed on how to implement the security policy.
I will iterate with spread test that shows what I implemented. I’m also consider splitting this so that the improved validation is cherry-picked into 2.31 (CC @mvo).
The security news is that layout mechanics needs to go through a hardening phase where snap-update-ns will come with an apparmor profile tailored to a given snap. This is my 2nd priority item after the spread test above
So the big picture is that things are mostly there for layouts. If you are keen to try them out you can grab master, look at the spread test for inspiration and start experimenting.
I’m still due to write a documentation chapter and that will be my focus after the code is ready. I will be taking a small detour to help land the per-user mount namespaces to help the desktop team with XDG portal support so I cannot say exactly how timing looks like.
Two PRs that fixed a bug affecting symlinks and read-only directories and layouts on core were merged both into master and into the 2.32 release branch. With those fixes layouts should now operate on core and classic without any major issues.
I will look into updating the documentation and I’m looking forward to 2.32
I was also made aware of an issue when refreshing try-mode snaps that are using layouts and I am investigating the issue. It looks like a bug in the update algorithm. I will post more updates as I get to the bottom of the issue.
Given that layouts are still a bit experimental we have decided to put them under feature flag.
To use layouts in 2.32 you will need to enable it with snap set core experimental.layouts=true.
but got the following error when running my app: cannot update snap namespace: cannot create writable mimic over "/usr/lib": permission denied;
and the following denial: [68891.838823] audit: type=1400 audit(1524071502.757:492): apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="snap-update-ns.scid" name="/tmp/.snap/usr/lib/" pid=15755 comm="3" srcname="/usr/lib/" flags="rw, rbind"
It seems that the directories prior to “tk8.5” must exist for layout to work - I got it working by bind-mounting everything at the /usr/lib/tcltk level.
Yes, when we grant permissions for snap-update-ns to construct a writable mimic we do so for the directory that was specified in the layout. The problem is that here we, at runtime, notice that /usr/lib/tcltk/ doesn’t exist and so decide to make a mimic at /usr/lib.
One way of fixing it would be to use the container work from Chipaca to inspect the base snap and know what we are dealing with. I need to think about other approaches.
@zyga-snapd There’s something a bit suspect in this constraint if all we are doing is allowing whatever the snap asks for. In other words, so we protect the environment from mounting into /usr/lib, unless the snap actually asked for it? Why?
Right, the point is that if the snap asks for /foo/bar/baz, we allow it. If it asks for /foo/bar, we allow it… so this is not strong security constraint in the sense we are actually allowing both, right? And now, apparently allowing /foo/bar/baz but not /foo/bar means things are breaking down. So why not simply allowing the parents as well?
I sent a PR summarising the problem and showing what the permissions we hand out are. I made a suggestion that follows what Gustavo suggested above and I will be making subsequent modifications but I need to discuss this with @jdstand briefly.
I have this fixed now and I will be making one or two PRs that introduce the fix. I also found one more interesting bug related to layouts in particular. I will summarise the details in the PRs and link them here.
I have omitted small PRs that just make the place for those three available. I will update the 1st link to refer to the actual fix (this is just a function for review so far) once that is available for review.
My gut feeling is that after one full cycle without known issues. Currently there’s still one^Htwo issues (aka “trespassing” bug and “chopTree” bug) that I’m working on (it’s a deeper problem than initially thought).