[apparmor] [Patch] [Bug 731184] Re: apparmor_parser fails to consider its own time stamp when determining if profile cache is stale
John Johansen
john.johansen at canonical.com
Tue Mar 8 22:13:33 UTC 2011
On 03/08/2011 11:26 AM, Kees Cook wrote:
> On Tue, Mar 08, 2011 at 10:50:58AM -0800, John Johansen wrote:
>> + cmd = fopen(progname, "r");
>
> Unfortunately, this won't work since "progname" may be relative to a
> PATH directory.
>
> $ /sbin/apparmor_parser -h | grep Usage
> Usage: /sbin/apparmor_parser [options] [profile]
>
> $ apparmor_parser -h | grep Usage
> Usage: apparmor_parser [options] [profile]
>
> I would suggest fully canonicalizing either progname or this fopen target
> using readlink(/proc/self/exe).
>
> I would learn toward the former, actually, so that invocation method
> doesn't change the Usage output, etc.
>
hrmm, I actually lean towards the latter, mostly because the usage message
matches how the parser was invoked.
Also if going with the latter we can just directly open /proc/self/exe
---
=== modified file 'parser/parser_main.c'
--- parser/parser_main.c 2011-03-03 23:45:10 +0000
+++ parser/parser_main.c 2011-03-08 22:05:04 +0000
@@ -805,6 +805,7 @@
char * cachename = NULL;
char * cachetemp = NULL;
char *basename = NULL;
+ FILE *cmd;
/* per-profile states */
force_complain = opt_force_complain;
@@ -852,6 +853,12 @@
update_mru_tstamp(yyin);
}
+ cmd = fopen("/proc/self/exe", "r");
+ if (cmd) {
+ update_mru_tstamp(cmd);
+ fclose(cmd);
+ }
+
retval = yyparse();
if (retval != 0)
goto out;
More information about the AppArmor
mailing list