Feature #8415: Migrate from aufs to overlayfs
overlayfs breaks AppArmor
At March, 2015 AppArmor meeting:
jjohansen: overlayfs is currently just broken, and we are going to be working with upstream to try to get it fixed darix: are the current issues documented somewhere? jjohansen: upstream has already begun working on fixing many of the issues involved we just need to make sure we are on top of it and providing them feedback, and maybe a patch or two if needed jjohansen: darix: only sort of in the lkml/fsdevel threads around the issues jjohansen: it affect more than just apparmor [...] jjohansen: to summarize, basically overlayfs took some short cuts and some places the hooks see the upper (overlayfs) dentry/vfsmnt jjohansen: and some places only see the lower dentry/vfsmnt (which is also a private clone mnt) tyhicks: darix: this is a decent placeholder bug to follow for the general overlayfs issue: https://bugs.launchpad.net/apparmor/+bug/1408106 jjohansen: once the overlayfs issues are fixed we should be good with doing unioning via overlayfs intrigeri: be sure that I'll (have to) test it, including with multiple lower-layers [...] jjohansen: intrigeri: yeah we will have to test it too, there are several projects that want to use it
#4 Updated by intrigeri about 4 years ago
- Feature Branch set to feature/8415-overlayfs
On current feature/8415-overlayfs, the profiles for Vidalia, Tor Browser and cupsd are loaded and enforced (so say
aa-status). However, indeed they don't seem to be effective: I could save a page into
~/.gnupg/ from Tor Browser.
#9 Updated by intrigeri over 2 years ago
Subgraph OS (live) uses overlayfs and enables AppArmor.
aa-status says that some processes (e.g. dhclient, NM and Tor) are confined.
I see some aliases set up:
alias / -> /lib/live/mount/overlay/, alias / -> /lib/live/mount/rootfs/filesystem.squashfs/, alias / -> /rw/,
I've started a feature/stretch ISO, dropped
union=aufs (so the default, i.e. overlayfs, is used), added
alias / -> /rw/,, added
flags=(attach_disconnected) to the
usr.bin.evince profile and it seems to behave as it should: Evince can open stuff in
/usr, but not in
~/.gnupg. So it might be that adding this flag to all the profiles we ship would be enough.