[Dovecot] deliver can't connect to auth server at */usr/local*/var/run/dovecot/auth-master

[Andreas Ntaflos]

On Tuesday 15 January 2008 03:56:28 Jerry Yeager wrote:
> > while fiddling around with the configuration so Dovecot's LDA
> > "deliver" can be
> > used by multiple users by means of Getmail (you can read about that
> > in [1]) I
> > always end up running into the error message posted in the subject
> > line:
> >
> > Jan 15 00:00:02 HOSTNAME deliver(USERID): Can't connect to auth server
> > at /usr/local/var/run/dovecot/auth-master: Permission denied
> >
> > Notice how it says "/usr/local/var/run/dovecot"! How and why does
> > dovecot
> >                    ^^^^^^^^^^
> > think that anything of any importance can be found under /usr/local/
> > var/... ?
> > Please see dovecot -n at the end of this message, but as far as I
> > can tell I
> >
> >    master:
> >      path: /var/run/dovecot/auth-master
> >      mode: 432
> >      user: root
> >      group: dovecot
>
> For the quick answer to your immediate problem / question, try:
>
> cd /path/to/dovecot's/deliver		(probably 	/usr/local/libexec/dovecot/  )
>
> chmod u+s deliver
>
> (enable the setuid bit for the deliver app). Your Getmail app may not
> be truly running as root and thus does not really have permission to
> do what you want.
>
> you may need to do the same for the group as well

Thank you as well for the reply! :)

Chmod'ing deliver really was a step forward in the right direction, although, 
as I mentioned elsewhere in this thread, I did not quite get the 
configuration right so a few messages from this and other mailing lists 
bounced because deliver wasn't called correctly. Still trying to figure that 
out. 

> Unix permissions are weird sometimes, like a $100 television tube that
> protects a 50 cent fuse by blowing first.

Really great analogy :) I never had a problem with understanding Unix 
permissions, but things seem to get complicated when you try to make 
different parts of a mail system running smoothly together.

> It does look like (from your use of /usr/local/*****) you built
> dovecot to run out of /usr/local.

No, I really didn't (as far as I can tell). The installation prefix 
is /usr/local, yes, but Dovecot runs out of /var/run/dovecot. But apparently 
the auth_socket_path for protocol lda defaults to /usr/local/var/run/dovecot, 
a parameter I'm still not sure what I need it for.

> One last thing, as a security idea, try something like
>
>       master {
>         path = /usr/local/var/run/dovecot/auth-master
>         mode = 0600
>         user = dovecot_user
>         group = dovecot_group
>       }
>
> and set your postfix line that calls deliver to match:
>
> 	dovecot unix - n n - - pipe flags=DRhu
> user=dovecot_user:dovecot_group argv=/usr/local/libexec/dovecot/
> deliver -f ${sender} -d ${recipient}

Thanks for this suggestion! But that would imply that I have a virtual user 
setup, wouldn't it? Because I don't, all my users are regular Unix users with 
shell accounts. That's why my Postfix main.cf contains just

home_mailbox = Maildir/
mailbox_command = /usr/local/libexec/dovecot/deliver

which is also what the LDA/Postfix wiki page says on wiki.dovecot.org. No 
Dovecot entry in master.cf at all.

And, as also mentioned elsewhere in this thread, until yesterday I didn't even 
have the master { ... } section uncommented, and no auth-master socket seems 
to have been configured. But then again I only delivered through Postfix and 
didn't need to have deliver called by a regular user.

Andreas
-- 
Andreas "daff" Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://dovecot.org/pipermail/dovecot/attachments/20080115/33439c1a/attachment-0001.bin