[apparmor] Bug#735470: Fwd: Bug#735470: Could be implemented centrally with a dpkg trigger instead of requiring every package shipping an apparmor file to use dh_apparmor
Seth Arnold
seth.arnold at canonical.com
Sat Jan 18 00:20:40 UTC 2014
[I've trimmed the Cc:, it didn't seem worthwhile to keep all this in the
Debian BTS in addition to the usual mail list archives.]
On Thu, Jan 16, 2014 at 04:15:35PM -0800, John Johansen wrote:
> It does not at the moment consider what is loaded into the kernel, but only
> works off of the cache time stamps. For older kernels there really isn't
> a way to check if what is loaded in the kernel is up to date. However
> for 3.12+ kernels we could leverage the policy dir to compare timestamps
> or if policy hashing is enabled we could compare to the sha1 stored for
> each profile that is loaded.
>
> we can of course also change the letter chosen
> @@ -873,6 +878,14 @@
> if (!skip_read_cache &&
> stat(cachename, &stat_bin) == 0 &&
> stat_bin.st_size > 0 && (mru_t_cmp(stat_bin.st_mtim))) {
> + if (update_only) {
> + /* cache hit means profile is not out of
> + * date so don't load
> + */
> + if (show_cache)
> + PERROR("skipping load of up to date: %s\n", cachename);
> + goto out; /* retval already 0 */
> + }
> if (show_cache)
> PERROR("Cache hit: %s\n", cachename);
> retval = process_binary(option, cachename);
I don't like this much; why wouldn't -u be the default?
I know that /etc/apparmor/parser.conf can be used to set default options,
but I like that even less -- the parser shouldn't behave differently from
system to system.
Most of the time --replace is the right option. Most of the time
--write-cache is the right option. And once we're happy with the
implementation of -u, it should probably be used for every --replace.
So why expose it to the user? Why not just do it?
Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20140117/b0525a18/attachment.pgp>
More information about the AppArmor
mailing list