[Dovecot] auth-master: Permission denied [sigh]

[James Butler]

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:
>> >> 1) User 'spam:dovecot' runs Smapassassin
>> >> 2) 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:
>>
>> 1) 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.

>> 2) 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.

>> >> 3) Deliver assumes 'user1:dovecot' identity
>> >> 4) Can't access auth-master in 'root:dovecot' directory (777)
>> >
>> > 4) 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:

1) 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.

2) user= is required.
3) user=${user} fails, as ${user} is not resolved.
4) 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