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
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
