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?
We don’t grant arbitrary mounts so we grant what the snap asks for. This is not specific to /usr/lib in any way.
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?
We disallow certain things so I need to think how to make us allow what is safe without breaking the earlier constraints.
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.
EDIT: PR is actually https://github.com/snapcore/snapd/pull/5074
I’ve implemented the proposed solution. I will push it shortly (just waiting for local run of spread with the extended layout test).
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.
EDIT: The 1st “PR” for chopTree is https://github.com/snapcore/snapd/pull/5081 (more things on the way for this effort though)
EDIT: The 2nd “PR” for the poke-hole in the source path for layouts: https://github.com/snapcore/snapd/pull/5090
EDIT: The 3rd “PR” for the mimic tmpfs mode and ownership: https://github.com/snapcore/snapd/pull/5107
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.
Hey, any word on when this will become officially supported (as opposed to experimental)?
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).
2.35 maybe?
I’m very much interested in this, and hope it will be available soon! Good work to all!
2.34 should have one (or with some luck) both of the remaining fixes merged. In any case the issues are very isolated and non earth-shattering so you can try to use layouts to make your snaps easier today.
Awesome, thank you! 
@zyga-snapd Did you mean 2.34 or 2.33.1? Because right after your answer, I have seen a 2.33.1 release, but there is still no 2.34! Sorry if I misunderstood you…
I meant 2.34, we will do a beta release today (and more next week). As the patch gets reviewed it will hopefully land and unbreak another part of layouts.
Woah, that was fast! I’ll keep my eyes open for the beta, then! Thanks again!
So when does this graduate to stable (non-experimental). I have a snap that uses this feature on a UbuntuCore system, that snap is supposed to be a kiosk app, so to ensure that it works on all systems, its highly important for this feature to leave “experimental” status.
There are still two bugs that prevent this from happening. I suspect that 2.36 is very likely though.
