On 03/23/2018 03:48 PM, Tyler Hicks wrote: > On 03/23/2018 12:10 PM, John Johansen wrote: >> On 02/06/2018 09:29 AM, Christian Boltz wrote: >>> Hello, >>> >>> Am Montag, 5. Februar 2018, 22:13:19 CET schrieb Marco d'Itri: >>>> On Feb 05, Jamie Strandboge <ja...@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) >> >> and this already exists (its not ready to land quite yet) in >> https://gitlab.com/jjohansen/apparmor/tree/multicache >> >> it supports overlay caches, where you can provide a list of cache >> locations that are to be searched in order >> >> --cache-loc=/A,/B,/C > > How do I use the cache location of /var/lib/larry,moe,curly with an > overlay using the relative path shemp/? Should we just accept multiple, > ordered --cache-loc's instead? >
so you can escape the comma if you really need to include it as part of a path name. As for using multiple ordered --cache-loc entries we could do that but I didn't because I wanted to leave that free so that we could potentially specify multiple policy sets to the parser in one invocations. using the supplied example policy file, something like apparmor_parser -r --cache-loc=/var/cache/apparmor,/etc/apparmor.d/cache --write-cache /var/libapparmor/,/etc/apparmor.d/ -- --cache-loc=/var/cache/apparmor --write-cache -O no-expr-simplify /var/lib/apparmor/ -- --cachel-loc=/var/cache/apparmor --write-cache /var/lib/snapd/profiles -b /var/lib/lxd/apparmor/cache currently that wouldn't buy us anything except having to do only a single parser invocation, but in the future I would like to get compilation being able to share certain computations and generate policy that shares some common pieces. The caveat being they are going to have to be compiled together to take advantage of it. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
