On Fri, Jun 05, 2015 at 03:24:23PM -0700, John Johansen wrote: > Currently the cache file has its mtime set to its creation time, but this > can lead to cache issues when a policy file is updated separately from > the cache file so that is possible a policy file is newer than the > what the cache file was generated from but still fails the comparison > because the generated cache file has a newer timestamp. > > Signed-off-by: John Johansen <[email protected]>
Acked-by: Seth Arnold <[email protected]> .. with one slight concern: > void update_mru_tstamp(FILE *file, const char *name) > { > struct stat stat_file; > + if (fstat(fileno(file), &stat_file)) > return; > + if (tstamp_cmp(mru_policy_tstamp, stat_file.st_mtim) < 0) > + /* keep track of the most recent policy tstamp */ > + mru_policy_tstamp = stat_file.st_mtim; > + if (tstamp_is_null(cache_tstamp)) > + return; > + if (tstamp_cmp(stat_file.st_mtim, cache_tstamp) > 0) { > if (debug_cache) > pwarn("%s: file '%s' is newer than cache file\n", > progname, name); > mru_skip_cache = 1; > + } > } Strictly speaking the pwarn isn't a _warning_ -- that would be a usual case when a file or included file is updated and then policy is reloaded. I think someone asking to debug the cache might be either (a) one of us, in which case we'll know to ignore the "Warning" text, or (b) someone in a tight spot who may not know to ignore the "Warning" text. Maybe this is a task for another day. Thanks
signature.asc
Description: Digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
