Hello, Am Montag, 10. Oktober 2011 schrieb Tim Edwards:
On Monday, October 10, 2011 1:54 AM, "Christian Boltz" wrote:
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
Looks like you have lots of modified profiles, including those for dovecot.
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
Add /proc/[0-]*/mounts r, or @{PROC}/[0-9]*/mounts r, to the usr.sbin.dovecot profile to get rid of this error. I'll also send a patch upstream to include this rule (the @{PROC} variant).
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?
That are two different things. a) rpm packaging The profiles are packaged as "%(config) %(noreplace)" in the apparmor- profiles package. This means rpm will never replace existing files if they are modified (like those rpm -V listed for you). Instead, you should get some *.rpmnew files with the new version. (Just for completeness: the apparmor initscript ignores *.rpmnew, *.rpmorig and some other "backup" files.) b) caching Caching means that a binary version of each profile is stored in the cache directory (/etc/apparmor.d/cache, which I made a symlink to /var/cache/apparmor/). If a profile is modified or added, apparmor_parser automatically (re)creates the cache file.
Ok, it looks like you guys are putting some effort into getting them to work.
Oh yes. I better don't count the hours I spent on AppArmor in the last months ;-)
aa-notify isn't started by default. If you want to use it, run
sudo DISPLAY=$DISPLAY /usr/sbin/aa-notify -p [...] Nothing's perfect I guess, but it'd be better not to have it working in the background blocking things with no notifications.
Feel free to allow password-less sudo for aa-notify and put it in your autostart folder ;-) Regards, Christian Boltz --
Aber der SuSE-Kernel wird mindestens ein Goodie haben, das auch du sehr zu schätzen wissen wirst. Er wird diesmal stabil laufen?? :-)) [> Philipp Thomas und Thomas Hertweck in suse-linux]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org