Bugzilla – Bug 156446
apparmor doesn't allow postfix to execute procmail
Last modified: 2006-04-20 11:47:02 UTC
In a SL10.1b7 default install (upgraded from 10.0): AppArmor: REJECTING exec(2) of image '/usr/bin/procmail'. Profile mandatory and not found (sh(27815) profile /usr/lib/postfix/local active /usr/lib/postfix/local) If the postfix system is configured to use procmail as the local agent, this will cause e-mails to be bounced! How about putting apparmor into logging only mode for the time being?
Or, in my setup, causing e-mails to get lost without notice. I'm not amused.
*** Bug 156706 has been marked as a duplicate of this bug. ***
BTW, there does not seem to be any kind of helpful error message in the mail system stack (fetchmail/postfix/procmail). Since I wholeheartily agree with Joerg's comment, I adjust the severity. Handing this kind of problem out at BrainShare would not be good PR...
Fixed. procmail now executes 'ux' (without a profile) when called from /usr/lib/postfix/local.
We should release an update for SLES9 SP3 since the profiles seem to be activated per default and break Mailman, too: /var/log/warn: Apr 4 15:11:21 leo kernel: SubDomain: REJECTING exec(2) of image '/usr/lib/mailman/mail/mailman', Profile mandatory (exec qualifier 'p' specified) and not found (local(6015) profile /usr/lib/postfix/local active /usr/lib/postfix/local) Apr 4 15:11:21 leo local[6015]: fatal: execvp /usr/lib/mailman/mail/mailman: Operation not permitted /var/log/mail: Apr 4 15:11:21 leo local[6015]: fatal: execvp /usr/lib/mailman/mail/mailman: Operation not permitted
AppArmor also breaks postfix in combination with UUCP: audit(1144098310.580:384): REJECTING w access to /var/spool/postfix/private/uucp (qmgr(4805) profile /usr/lib/postfix/qmgr active /usr/lib/postfix/qmgr) (Not sure whether it would cause further issues if any child processes were started by postfix/uucp. I needed my e-mail and switched AppArmor to "taboo" in YaST2.) I'm not convinced our profiles have seen enough real-world useage yet to be shipped active and in enforcer mode yet. We should entertain the idea of not enabling all of them by active, and suggesting that people activate them in learning mode first (and also figure out some way of getting feedback on the things which are missing in our profiles). Or else we'll pull off an SELinux and everybody will do what I did and disable AppArmor completely...
Hmm. I will fix this profile and check it in. Not sure how to evaluate the larger question. We have exercised the postfix profile - our efforts were around yast configuration options. Its somewhat expected that you may need to customize the policy for your specific env - and thats what the tools are for (logprof in this case). Lars thanks for the report - is your uucp config based on a yast config? Is it all mail going out to a uucp relay (default_transport)? If you can elaborate a bit on the use case I can duplicate it and ensure that the postfix profiles are inclusive of it. I'll take Heikos report to a separate BZ for sles9sp3 (so we can track and release a maintenance fix)
This profile error was fixed and is checked into abuild. There may be further changes subsequent to more involved use cases covering uucp transport (currently being performed).
Similar problem in rc1: fetchmail fetches the mail, then postfix runs basically into this problem: Apr 20 11:20:30 coredump postfix/local[5946]: warning: cannot open file /suse/rplewe/.forward: Operation not permitted The .forward has permissions 644. Mail is then delivered into /var/mail/plewe directly, instead of being piped through procmail (via the .forward). Since the mail is not lost I lower the priority.
rasmus did you add "/suse/" to /etc/apparmor.d/tunables/homes:@{HOMEDIRS}?
Oops. My bad. Sorry for the noise -> closed again.