had to chmod u+s procmail after edgy dist-upgrade
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
procmail (Ubuntu) |
Fix Released
|
High
|
Martin Pitt |
Bug Description
Binary package hint: procmail
Might alternatively be a bug in postfix, or a low-probability bug in the Edgy dist-upgrade procedure.
Possibly due to postfix running a piped delivery program in /etc/aliases with lower permissions than previously ?
entry in /var/log/mail.log:
Oct 27 11:31:10 localhost procmail[10839]: Insufficient privileges to deliver to "rich"
entry in /etc/aliases:
rich-filter: "|/usr/
permissions on mailbox:
root@saturn:
total 15332
-rw-rw---- 1 rich mail 15636626 2006-10-27 13:08 rich
permissions on procmail executable
before fix:
root@saturn:
-rwxr-sr-x 1 root mail 71664 2006-07-10 11:00 /usr/bin/procmail
permissions on procmail executable
after fix:
root@saturn:
-rwsr-sr-x 1 root mail 71664 2006-07-10 11:00 /usr/bin/procmail
explanation:
fetchmail gets mail from MTA host, delivers to rich-filter via postfix. tagspam.py is my own spam filter program which delivers to the rich mailbox using procmail - but the same setup was OK with just setgid on procmail on Dapper, and now procmail needs setuid on Edgy. Does my fix open one security hole after another has been closed ? Also this could have resulted in lost mail if I hadn't tested very soon after the upgrade. Might only affect use of procmail following a privilege reduction in a new postfix version ?
Related branches
description: | updated |
Changed in procmail: | |
assignee: | nobody → pitti |
Changed in procmail: | |
status: | Confirmed → In Progress |
importance: | Undecided → High |
Ran into same problem on feisty herd-5. I am using msmtp instead of postfix, so I think it rules out that the issue is in postfix. The chmod u+s procmail change also fixed it for me.