Am 07.02.20 um 23:42 schrieb Christian Boltz:
Hello,
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 before? ;-)
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 ;-)
Please 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.
If you 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" pid=3405 comm="nscd" requested_mask="r" denied_mask="r" fsuid=0 ouid=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 /{usr/,}etc/services r, 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/, strolchi:/etc #
Usually I don't use nscd [1], 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 nscd-2.30-2.2.x86_64 strolchi:/etc # rpm -V nscd strolchi:/etc #
Instead of using aa-teardown, can you please re-enable AppArmor and set the nscd profile into complain (learning) mode? aa-complain /etc/apparmor.d/usr.sbin.nscd (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 mode.)> After having nscd run for a while, check if you get ALLOWED log entries for it.
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.
[1] 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. -- Stefan Seyfried "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@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org