Hi Debian Kernel Team,

intrigeri (2014-12-11):
> Ben Hutchings wrote (09 Dec 2014 19:55:10 GMT) :
>> Please try the Linux 3.18 packages from experimental (they're not there
>> yet, but should be soon) and check that overlayfs does what you need.
>
> Thanks. I'll test it for Tails' usecases (that use aufs a bit more
> than most other live systems, e.g. our incremental upgrades features
> uses it) once I find the time to.

It took us a while, but I'm happy to report that Tails has finally
migrated away from aufs! So as far as Tails is concerned, we don't
need the aufs "compat" patchset in src:linux anymore :)

In passing, so that I can call "case closed" some of the blockers that
were discussed later on this thread back in 2014-2015:

1. overlayfs stack depth upper limit vs. live-boot SquashFS stacking feature

   It turns out that was a misunderstanding: that upper limit applies
   to how many overlayfs filesystems can be part of a new overlayfs
   mount, rather than to how many read-only lower layers it's
   built from.

2. overlayfs vs. AppArmor

   It's still true that out-of-the-box, just like aufs, overlayfs does
   not play well with AppArmor. That's why apparmor.service turns
   itself into a no-op when it detects a Debian or Ubuntu Live system.

   To make them work together, one solution is to add a few AppArmor
   `alias` rules, and to add the `attach_disconnected` flag to every
   profile. For example:

    - 
https://salsa.debian.org/tails-team/tails/-/blob/master/config/chroot_local-includes/etc/apparmor.d/tunables/alias.d/tails
    - 
https://salsa.debian.org/tails-team/tails/-/blob/master/config/chroot_local-hooks/48-tweak-AppArmor-profiles
    - https://tails.boum.org/contribute/design/application_isolation/

Cheers!

Reply via email to