Am 07.02.20 um 23:42 schrieb Christian Boltz:
Am Donnerstag, 6. Februar 2020, 09:04:27 CET schrieb Stefan Seyfried:
Am 05.02.20 um 20:29 schrieb Christian Boltz:
Silly question - why did you switch it off
Because it always™ breaks something ;-)
No, apparently I actually did not disable it after the last reinstall
on this machine IIRC, I need to improve my documentation for reinstall
to not forget this again ;-)
Well, actually you just confirmed what I see whenever I give my
"AppArmor Crash Course" talk ;-)
I always ask the audience to raise hands if they a) use AppArmor and
b) use AppArmor "accidently" (because they use (open)SUSE, Ubuntu,
Debian Buster etc.)
For b) I usually see at least twice the hands as for a) - which means
that AppArmor typically just works in the background, doesn't cause
trouble, and most people even don't notice that it's active ;-)
check if you have *.rpmnew files in /etc/apparmor.d/ or
/etc/apparmor.d/abstractions/ - one of the latest snapshots included
updated abstractions for the /usr/etc/ move.
Exactly. I checked the changelog and even rebooted to make sure
everything is fine.
OK, the reboot includes reloading the profiles - which would have been
my first guess.
don't have any *.rpmnew files and still see problems, please
open a bugreport with your /var/log/audit/audit.log (you can grep
for "apparmor" if you don't want to attach the whole file).
It boils down to:
type=AVC msg=audit(1580924683.326:179): apparmor="DENIED"
operation="open" profile="nscd" name="/usr/etc/services"
comm="nscd" requested_mask="r" denied_mask="r" fsuid=0
And I don't understand why by reading the apparmor config.
But "aa-teardown;systemctl disable apparmor" fixed it for me.
Hmm, that's really strange, and shouldn't happen - as you already wrote
in a later mail, abstractions/nameservice includes
which should cover this.
Just to be sure, please check if
rpm -V apparmor-profiles apparmor-abstractions
lists any modified files.
strolchi:/etc # rpm -V apparmor-profiles apparmor-abstractions
S.5....T. c /etc/apparmor.d/tunables/alias
strolchi:/etc # grep -v ^# /etc/apparmor.d/tunables/alias
alias /var/lib/libvirt/ -> /space/.vmspace/libvirt/,
Usually I don't use nscd , but I just started
it and let it run for
two hours - without a denial in audit.log. (Just wondering, even if your
denial is completely strange - do you use a non-default nscd config?)
I don't think so:
strolchi:/etc # rpm -qf /etc/nscd.conf
strolchi:/etc # rpm -V nscd
Instead of using aa-teardown, can you please re-enable
AppArmor and set
the nscd profile into complain (learning) mode?
(I guess you know what complain mode does, but for the wider audience:
complain mode means everything is allowed, and things that would be
denied get logged. There's also aa-enforce to switch back to enforce
After having nscd run for a while, check if you get ALLOWED log entries
Now it seems to work, even in enforce mode...
...and that's why I keep apparmor disabled usually ;-)
I'm now rebooting to check if it still works after reboot.
 it caches "too much" for me, and since I
run a local nameserver,
nscd isn't too useful ;-)
if you use network based authentication, "no nscd" is not an option.
"For a successful technology, reality must take precedence over
public relations, for nature cannot be fooled." -- Richard Feynman
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org