(In reply to Christian Boltz from comment #14) > > ... operation="exec" profile="/usr/bin/lessopen.sh" name="/usr/bin/id" > pid=32146 comm="lessopen.sh" requested_mask="x" denied_mask="x" fsuid=223 > ouid=0 > > so lessopen.sh wants to execute "id" - but I don't see any "id" call in my > Tumbleweed lessopen.sh. Do you have a different lessopen.sh, or am I just > blind? (Allowing to run "id" doesn't look like a serious security issue > (especially because the profile already allows reading everything including > /proc/self/status) - but of course it should only be allowed if it's really > needed.) > This id call was added for debugging only as I've checked out which which id for lessopen.sh is used if less is used by root > > And finally, there is (before you switched the profile into complain mode): > > type=AVC msg=audit(1509081678.576:3010): apparmor="DENIED" > operation="unlink" profile="/usr/bin/lessopen.sh" > name="/usr/bin/lessopen.sh" pid=30470 comm="rm" requested_mask="d" > denied_mask="d" fsuid=0 ouid=0 > > So for some reason lessopen.sh tried to delete itsself (by calling "rm") > this morning :-/ The exact time is: > # date -d @1509081678 # the number after msg=audit is the unix timestamp > Fr 27. Okt 07:21:18 CEST 2017 Bug in my test code, fixed > (In reply to Dr. Werner Fink from comment #9) > > with > > > > network inet dgram, > > network inet stream, > > network unix dgram, > > network unix stream, > > > > the file command returns the corect identifier in both user abd toot case > > The two "network unix" streams are only needed until AppArmor 2.11.1 reaches > Tumbleweed - there was a a bugfix in apparmor_parser which only showed up in > combination with kernel 4.14 rc2 and newer. (Dominique just accepted the > staging project, so it should be in one of the next snapshots.) > > The two "network inet" rules are probably related to NFS - I'm still waiting > for an answer from upstream.