On Monday, October 10, 2011 1:54 AM, "Christian Boltz"
Apparmor definitely did break my simple local-users only Dovecot setup though, and the bug I raised was closed as fixed even though it wasn't for me.
I guess you are talking about https://bugzilla.novell.com/show_bug.cgi?id=681267
Yes
I don't have the 11.4 profiles here at the moment (I'm using factory), so I can't check it right now.
But I'll help you to solve the problems you see ;-)
First check if you are using the profiles from the apparmor-profiles package or modified (maybe outdated) profiles: rpm -V apparmor-profiles
S.5....T. c /etc/apparmor.d/bin.ping S.5....T. c /etc/apparmor.d/sbin.klogd S.5....T. c /etc/apparmor.d/usr.lib.dovecot.deliver S.5....T. c /etc/apparmor.d/usr.lib.dovecot.dovecot-auth S.5....T. c /etc/apparmor.d/usr.lib.dovecot.imap S.5....T. c /etc/apparmor.d/usr.lib.dovecot.imap-login S.5....T. c /etc/apparmor.d/usr.lib.dovecot.managesieve-login S.5....T. c /etc/apparmor.d/usr.lib.dovecot.pop3 S.5....T. c /etc/apparmor.d/usr.lib.dovecot.pop3-login S.5....T. c /etc/apparmor.d/usr.sbin.avahi-daemon S.5....T. c /etc/apparmor.d/usr.sbin.dnsmasq S.5....T. c /etc/apparmor.d/usr.sbin.dovecot S.5....T. c /etc/apparmor.d/usr.sbin.nmbd S.5....T. c /etc/apparmor.d/usr.sbin.ntpd S.5....T. c /etc/apparmor.d/usr.sbin.smbd S.5....T. c /etc/apparmor.d/usr.sbin.traceroute
If you see anything related to dovecot in the output, please mv /etc/apparmor.d/*dovecot* /some/where/ zypper in -f apparmor-profiles rcapparmor reload
If you still see problems, please - switch the dovecot profiles to complain mode: aa-complain /etc/init.d/*dovecot* - run dovecot for some time - open a new bugreport and attach your audit.log.
It seems to be working now, although I still get this error: Oct 10 12:48:24 localhost kernel: [1375671.879183] type=1400 audit(1318243704.530:53): apparmor="DENIED" operation="open" parent=21582 profile="/usr/sbin/dovecot" name="/proc/21657/mounts" pid=21657 comm="dovecot" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Does the caching feature you were talking about earlier in the thread fix this need to move the profiles from /etc/apparmor.d/ for them to update properly?
Maybe, but after my experience with dovecot I got the impression that the Apparmor profiles weren't widely tested and were bitrotting. Maybe that's changed recently though.
The problem is that many programs behave different depending on their configuration and usage, which makes it hard to create a perfect profile.
To give you an example: traceroute (which is a quite simple program when compared to dovecot) had a good profile. Well, except if you used the -I flag... (see bug 685674)
But this example also shows that the profiles are not bitrotting ;-)
Ok, it looks like you guys are putting some effort into getting them to work.
Besides that, the default advice in this case should be "check /var/log/audit/audit.log and open a bugreport if needed".
It's not exactly user friendly. Can't it use the desktop notification thing (whatever it's called) to pop-up a notification when it blocks something?
aa-notify isn't started by default. If you want to use it, run sudo DISPLAY=$DISPLAY /usr/sbin/aa-notify -p
Unfortunately aa-notify is slightly broken in 11.4. If you want to use it, run chmod 750 /var/log/audit or install the packages from security:apparmor:factory. Factory already contains the working version.
BTW: the need for handing over $DISPLAY is caused by the very secure sudo config in openSUSE - it resets most environment variables. Maybe I get a more user-friendly way implemented upstream, but I'm afraid you'll always have to hand over $DISPLAY (or $DBUS_SESSION_BUS_ADDRESS) to aa-notify. Yes, I'm aware that this isn't a perfect solution, but it's the best I can offer for 12.1.
Nothing's perfect I guess, but it'd be better not to have it working in the background blocking things with no notifications. Tim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org