Short version: In the syslog-ng profile, ``` @{CHROOT_BASE}="" @{CHROOT_BASE}/@{run}/syslog-ng.pid krw, ``` works in 4.1 - but in 5.0 I get a denial when restarting syslog-ng: apparmor="DENIED" operation="mknod" class="file" profile="syslog-ng" name="/run/syslog-ng.pid" pid=3281 comm="syslog-ng-main" requested_mask="c" denied_mask="c" fsuid=0 ouid=0 I tested loading the 4.1 profile (and also the 5.0 profile with @{exec_path} replaced) with the 4.1 parser (latest git branch), and don't get a denial when restarting syslog-ng. This might be a regression in removing duplicate slashes after variable expansion, especially if the first variable is empty. When testing with the syslog-ng profile, with the 5.0 `apparmor_parser -S --skip-cache`, the variant `@{CHROOT_BASE}/@{run}` vs. `@{CHROOT_BASE}@{run}` give me different binary profiles. Doing the comparison with the 4.1 parser gives me the same binary for both variants. However, testing with a minimal profile with 4.1 also gives me different binary profiles with and without a slash between the variables, so either this isn't a regression, or there's something special in the syslog-ng profile that prevents the issue in the 4.1 parser. The minimal test profile I used: ``` @{empty}="" @{path}=/run/ profile slash { @{empty}/@{path}/foo r, # @{empty}@{path}/foo r, # alternative rule without slash between vars } ``` Note that this minimal test profile does NOT mirror exactly what happens in the syslog-ng profile since it also gives different binary profiles with the 4.1 parser. Longer version from IRC: ``` <cboltz> apparmor="DENIED" operation="mknod" class="file" profile="syslog-ng" name="/run/syslog-ng.pid" pid=3281 comm="syslog-ng-main" requested_mask="c" denied_mask="c" fsuid=0 ouid=0 <cboltz> but the profile already has <cboltz> @{CHROOT_BASE}="" <cboltz> @{CHROOT_BASE}/@{run}/syslog-ng.pid krw, <cboltz> so - any idea why I get this denial? <roddhjav> Can you try with @{CHROOT_BASE}@{run}/syslog-ng.pid krw, ? <cboltz> good idea - that indeed helps :-) <cboltz> with the / between the two variables, restarting syslog-ng gives me the denied message - and after removing it, the denial is gone <cboltz> now I wonder if this is a new issue in 5.0, or if I overlooked it all the time <cboltz> something to test tomorrow, I guess ;-) <cboltz> ok, compiling a 4.1 parser from git isn't that hard - and with that, I don't get the denial when restarting syslog-ng (using the syslog-ng profile from the 4.1 branch) <cboltz> so this is probably a regression in how duplicate slashes get removed <roddhjav> I had similar issues with @{att}/@{var} before. I don't think it is new. <cboltz> was this with @{att}="" or with @{att}=/some/path ? <cboltz> hmm, interesting - if I test with the syslog-ng profile, the 4.1 parser produces the same binary file with and without the slash <cboltz> but if I test with a minimal test profile, it gives me different binary profiles <cboltz> so there must be something else in the syslog-ng profile (or an abstraction) that prevents a difference when using the 4.1 parser ``` For completeness, in case you wonder: I also got a denial for syslog-ng.ctl which has a similar rule in the profile.