[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