Thank you for your continued attention, Timo.
On Tue, 2009-04-14 at 10:22 -0700, James Butler wrote:
On Mon, 2009-04-13 at 15:48 -0700, James Butler wrote:
- User 'spam:dovecot' runs Smapassassin
- Hands off to deliver (root:dovecot)
Have you set up some kind of setuid-root deliver, or why is it running as root:dovecot here instead of spam:dovecot?
I have no idea how it is running, except for these clues:
- Deliver is owned by root:dovecot
That makes no difference what the file's owner is.
Ok. I'm looking at the "Multiple UID" section, here ... it seems to indicate otherwise.
- When Spamassassin executes and then its output gets piped to Deliver WITHOUT a '-d ${user}' parameter, mail gets delivered to 'spam'
So it seems like Spamassassin IS running as user 'spam:dovecot'.
Not necessarily.
Hmm. I don't understand this. See my master.cf entry, below. (Sorry I didn't reference it directly in that last message. I've posted it, previously.)
Then it hands off to Deliver which starts out as being owned by root:dovecot. The runtime parameters instruct Deliver to switch from its default ownership to 'user1:dovecot', AFAICT.
deliver can't change any ownership to anything unless it runs as root, which can't happen unless spamassassin somehow executes deliver as root, which I doubt.
I'm pretty sure the problem is that spamassassin isn't running as spam:dovecot.
See my master.cf entry, below.
- Deliver assumes 'user1:dovecot' identity
- Can't access auth-master in 'root:dovecot' directory (777)
- happens before 3).
But my error (4) is labeled with:
deliver(user1):
Does that not indicate that Deliver has switched from its default ownership to run as 'user1',
No. The "user1" just means that it's going to deliver the mail to that user. It doesn't tell anything about what permissions the process is actually running with.
How can I determine which permissions the 'deliver' process is actually running with? I don't see it running with any permutation of 'ps'.
My guess is that deliver isn't really started with dovecot group permission.
My settings in Postfix's master.cf instruct:
/usr/local/libexec/dovecot/deliver -f ${sender} -d ${user}
If: ${user} = user1:dovecot
Then isn't deliver being executed as user1:dovecot?
No. You didn't show the full master.cf line. Typically deliver is executed via pipe, such as:
dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/deliver -f ${sender} -d ${recipient}
The important part there is the user=vmail:vmail part. It's executed as that user.
Here's my current, non-working entry (referenced above):
spamassassin unix - n n - - pipe user=spam:dovecot argv=/usr/bin/spamc -f -e /usr/libexec/dovecot/deliver -f ${sender} -d ${user} -m ${extension}
Here's the one where all mail gets delivered to user 'spam':
spamassassin unix - n n - - pipe user=spam:dovecot argv=/usr/bin/spamc -f -e /usr/libexec/dovecot/deliver
Here's the one without Spamassassin that delivers to the recipient:
dovecot unix - n n - - pipe /usr/libexec/dovecot/deliver
NOTE:
- spamassassin unix - n n - - pipe user=USERNAME argv=/usr/bin/spamc -f -e /usr/libexec/dovecot/deliver
Runs through Spamassassin and then delivers to USERNAME.
- user= is required.
- user=${user} fails, as ${user} is not resolved.
- user=root fails because I'm not allowed to run SA as root in this context
And would I really need to put ALL of my users into the same (dovecot) group just to be able to get mail to them? That would make little sense to me, as the whole point of using groups would be eliminated.
If you're using multiple UIDs, you typically have to run deliver as setuid-root: http://wiki.dovecot.org/LDA#multipleuids
Here's from the doc page you referenced, which I have read many, many times:
Multiple UIDs
If you're using more than one UID for users, you're going to have problems running deliver. Most MTAs won't let you run deliver as root, so for now you'll need to make it setuid root. However it's insecure to make deliver setuid-root, especially if you have untrusted users in your system. Setuid-root deliver can be used to gain root privileges. You should take extra steps to make sure that untrusted users can't run it and potentially gain root privileges. You can do this by making sure only your MTA has execution access to it. For example:
# chgrp secmail /usr/local/libexec/dovecot/deliver # chmod 04750 /usr/local/libexec/dovecot/deliver # ls -l /usr/local/libexec/dovecot/deliver -rwsr-x--- 1 root secmail 4023932 2009-01-15 16:23 deliver
Then start deliver as a user that belongs to secmail group.
Is this saying that Dovecot is designed for a mail system with only ONE UID, and that systems with MANY UIDs are exceptions?? I don't think so ... Dovecot works fine with multiple UIDs in my configuration when it's running by itself. If ALL users MUST be in the same group in order for this to work, so be it.
Is there a difference between the 'secmail' group in the docs and the 'dovecot' group in my config? Maybe, but I can't see where.
The only thing I know for sure is that when I use the '-d ${user}' parameter in master.cf, the ${user} has no permission to access/execute auth-master, regardless of '/var/run/dovecot' directory permissions.
If I omit that parameter, and let Deliver keep running as user 'spam', mail gets delivered (to 'spam').
Without -d parameter deliver doesn't do auth lookup at all, it just tries to figure out where to save the mail using the environment.
I understand that part. That's is why 'spam' gets all the mail without the -d parameter ... it's the user running Spamassassin, and then, Deliver. Or am I completely off base?
Here's my Deliver ownership/perms, again:
-rwxr-xr-x 1 root dovecot 4044835 2009-04-03 13:52 deliver
Shouldn't there be an 's' in there, somewhere?
If there's a 's' in there, then deliver is running setuid-root. It sounds like that's what you want.
I have again run chmod ug+s /usr/local/libexec/dovecot/deliver:
-rwsr-sr-x 1 root dovecot 4044835 2009-04-03 13:52 deliver
(Except for the world read/execute, it looks like the example from the docs.)
No change ... same error, same non-delivery after spam-checking.
(I try to reset my stuff to whatever it was before a test so my tests don't get screwed up by multiple variables and so that I can return to the working config when the test is done. I have reverted the permissions on 'deliver' back to 755, as they were before this most-recent test, and as they were in my previous post.)
I am going to post a followup with all of my config/perm/owner stuff for easy reference. I apologize in advance ... the trees are getting lost in the forest, for me.
Thank you for your patience.
James