not really, comm= added by the audit subsystem and is set by the thread
the check is being done in, in kernel context. Both the send and
receive check are being done in the same place so comm= will not change.
We are not in control of this so there is little we can do about it.
--
You received
Just to make sure this doesn't get lost/overlooked:
# Oddly, comm=kill is in both denials, despite the denials being for
send and receive masks
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1317555
Hit this bug again while trying to use:
http://bazaar.launchpad.net/~apparmor-dev/apparmor-profiles/master/view/head:/ubuntu/14.04/usr.lib.postgresql.bin.postgres
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Tags added: aa-parser
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1317555
Title:
'signal peer=@{profile_name},' does not work as expected when in a
profile using a regex match as a name
To
** Changed in: apparmor
Importance: High = Medium
** Changed in: apparmor (Ubuntu)
Importance: High = Medium
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1317555
Title:
'signal
Is this bug actually 'High' priority? It seems more like medium or
possibly low.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1317555
Title:
'signal peer=@{profile_name},' does not work as
Thanks for helping debug this! Similarly, using the extended profile
name and executable path definition style:
profile test /tmp/test/{kill,sleep} {
...
works too, without need for aa-exec -p. With that work-around, I'm able
to get my profile running happily again.
--
You received this bug
John says that the bug is in the parser:
11:18 jjohansen tyhicks: so the problem is the profile name vs. the
expression
11:20 tyhicks I'm not following
11:20 jjohansen the profile name when a regex is used is the literal string
11:20 jjohansen /{a,b} { }
11:20 jjohansen is equiv to
11:20
Here's a patch for the automated parser tests that can be used to verify
the fix for this bug.
** Patch added:
0001-parser-Equality-tests-for-peer-profile_name-and-patt.patch
