[apparmor] AppArmor and /etc/

[intrigeri]

Hi,

Jamie Strandboge:
> On Sat, 2018-07-07 at 21:33 +0200, intrigeri wrote:
>> > It continues to be a tricky problem. I think mostly we really
>> > need to make sure the binary policy is on the same partition as
>> > the text policy.
>> 
>> As you needed in the message I'm replying to, we run
>> After=local-fs.target, so I don't understand this part. I know you
>> have experience with shipping AppArmor policy (and the corresponding
>> cache) in /var so I'm sure I'm missing something. To enlighten me,
>> can
>> you please explain why this is a requirement or point to examples of
>> why it's a tricky problem?

> With this directive, the requirement isn't needed, but of course this
> only is going to be true on systemd-enabled systems.

OK, thanks for the clarification. Glad we're on the same page :)

I've filed Debian#904637 to track the next steps and have started
implementing it.

> For non-systemd systems, then this requirement stands.

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?

Cheers,
-- 
intrigeri