[apparmor] AppArmor and /etc/

[intrigeri]

Christian Boltz:
> 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.

Right.

> 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.

I'm not concerned about slowing down boot in this corner case.
Instead, I am/was concerned about breaking the boot. But it seems that
the parser returns a zero exit code even when its cache-loc is not
present: a "libapparmor[$pid]: Can't create cache location
'/non/existing': No such file or directory" message is logged but
apart of the profiles are loaded just fine. So indeed, maybe there's
simply no risk of breaking the boot by keeping $local_fs as-is.

> Therefore I'd vote to keep the $local_fs requirement, even if it slows 
> down boot in corner cases with non-local /var.

After doing the aforementioned tests, I now agree. But when reviewing
my tentative MR to implement this change, Jamie wrote that he agreed
with switching to $remote_fs, so I'm wary of reverting this change.

Jamie, what's your reasoning behind "I was leaning towards this too"
on https://salsa.debian.org/apparmor-team/apparmor/merge_requests/9?
Would you mind if I reverted to $local_fs, with the above rationale?

Cheers,
-- 
intrigeri