[apparmor] AppArmor and /etc/
Christian Boltz
apparmor at cboltz.de
Thu Jul 26 15:37:33 UTC 2018
Hello,
Am Donnerstag, 26. Juli 2018, 13:46:37 CEST schrieb intrigeri:
> The initscript has this:
>
> # Required-Start: $local_fs
>
> … so I think we should be good when pid 1 == sysvinit as well as long
> as /var is not on a remote FS.
>
> Then I'm hesitating between:
>
> a) Assume this very unlikely corner-case simply won't be triggered on
> real-life Buster or newer systems, and then either leave it at that
> or document in README.Debian that one must s/local_fs/remote_fs/ when
> using sysvinit + AppArmor + non-local /var.
>
> b) Replace that stanza with "Required-Start: $remote_fs"
>
> - pros: avoids the risk of breaking boot in this (corner) case
> - cons: some services may be started before AppArmor and thus not
> get the expected confinement unless they explicitly order
> themselves after apparmor
>
> Thoughts, opinions?
b) has the big disadvantage that it has to wait for the network (and
possibly dhcp to provide an IP address), which makes it *very* late in
the boot cycle, especially if dhcp is used. This obviously means that
some (most?) services will be started before their profile gets loaded.
OTOH, if a remote /var/ is really not mounted yet, you "only" loose the
profile cache. That slows down boot / loading the profiles, but is still
better than waiting for $remote_fs IMHO.
Therefore I'd vote to keep the $local_fs requirement, even if it slows
down boot in corner cases with non-local /var.
Regards,
Christian Boltz
--
> ist cyber-top(1) nicht das Tool um anzuzeugen welcher Prozess
> gerade wie viel rum-cybert? A la top(1), iotop(8) etc.
.. und isotopp(8) nicht zu vergessen..
[Evgeni Golov und Christian Bricart zu
https://plus.google.com/+KristianKöhntopp/posts/VV5tiv8yFF4]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20180726/fa7bfb48/attachment.sig>
More information about the AppArmor
mailing list