On Sat, 2018-07-07 at 21:33 +0200, intrigeri wrote: ... > > > > With that said /var/cache isn't terrible and is better that /etc/ > > > for most modern linux systems. I will also throw in the proviso > > > that > > > I don't mess with this area much and Jamie or Steve are better > > > people > > > to comment on this. > > > > > > > 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. For non-systemd systems, then this requirement stands. > FTR, according to Christian [1], openSUSE uses /var/cache/apparmor/ > for the profile cache and /usr/share/apparmor/cache/ for the > read-only/packaged version. > > [1] https://gitlab.com/apparmor/apparmor/merge_requests/134 > As stated elsewhere, Ubuntu has used /var/cache/apparmor for non-system policy related to Ubuntu Touch and snapd. That said, Touch is gone and snapd prepends 'snap.' to all snapd policy and lets apparmor_parser manage the directory, so the fact that snapd specifies it for --cache- loc is not a vote against moving system policy there. -- Jamie Strandboge | http://www.canonical.com
signature.asc
Description: This is a digitally signed message part
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
