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. 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?) 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. If you don't find an obvious reason for the problem, feel free to send me a tarball of your /etc/apparmor.d/ (off-list), and I'll have a look at it. Regards, Christian Boltz [1] it caches "too much" for me, and since I run a local nameserver, nscd isn't too useful ;-) -- <cboltz> oh, "test is green" fails? nice ;-) <tampakrap> hahahaha yes <tampakrap> we never thought of that scenario [from #opensuse-admin] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org