[apparmor] AppArmor and /etc/

[Christian Boltz]

Hello,

Am Montag, 5. Februar 2018, 22:13:19 CET schrieb Marco d'Itri:
> On Feb 05, Jamie Strandboge <jamie at canonical.com> 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. If we start thinking of it as binary policy, perhaps we can
> > instead put it in /lib. Eg, /lib/apparmor/policy. FHS adherents will
> > argue that this isn't the right place, but /etc is no better and the
> > FHS doesn't handle early boot well at all (this is presumably why
> > system uses /lib/systemd/system).
> 
> If the binary policy may change when /etc is changed then the only
> options are /etc/ and /var/.
> Please please please do not break this: /lib (which nowadays is
> a symlink to /usr/lib) is immutable and can be shared between systems.

Agreed, but let me mix in another idea/discussion we [1] had at FOSDEM:

What about using an override directory - /usr/something for cache files 
_shipped in the packages_ (for unmodified profiles), and /var/something 
to handle the cache for modified profiles.

I know this means some additional code in the parser, but would make 
packaging a pre-built cache much easier when it comes to avoiding 
*.rpmnew files etc.

The way this could work would be:

a) for reading the cache / loading a profile
- check if there's a valid cache file in /var/something and use it
- otherwise check if there's a valid cache file in /usr/something and 
  use it
- otherwise write the cache file to /var/something

b) for writing the cache
- write to /var/something by default
- write to /usr/something only when using 
      apparmor_parser --cache-loc /usr/something

c) for --purge-cache
- only delete files in /var/something (except if --cache-loc is used)


Regards,

Christian Boltz

[1] John, Richard Brown [2] and I

[2] Richard works on openSUSE Kubic (basically a special distribution 
    with/for Kubernetes) which has a read-only filesystem - you probably 
    remember the parser patches we already added to unbreak this usecase 
    ;-)
-- 
The updated behavior seems to be that this is happening on a weekly
basis like clockwork. The problem disappears approximately somewhere
between Wednesday to Saturday each week, only to reappear somewhere
approximately Sunday to Wednesday each week. [Ton Su in bnc#727586]
-------------- 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/20180206/dcabda6c/attachment.sig>