The Question is if that Process needs to be root or not. And as long as i dont know whos talking to that process and why it runs as default as root i wouldnt touch it.
It would make sense if its running as root when userdb is pam to access the files or its running as root because noone should have root rights and so noone can read the whole userdb. In that last case it would be really bad to switch the user from root to vmail :)
In my case all mails are stored with user vmail, maybe user vmail needs to be able to read the hole db
I dont know :) If someone know, let me know Hans
2010/8/31 Egbert Jan van den Bussche egbert@vandenbussche.nl:
Op 31-8-2010 2:13, spamvoll@googlemail.com schreef:
Hi..
im still trying to upgrade to 2.0. Im getting: dovecot: lda: Error: userdb lookup: connect(/var/run/dovecot/auth-userdb) failed: Permission denied (euid=10000(vmail) egid=10000(vmail) missing +r perm: /var/run/dovecot/auth-userdb, euid is not dir owner)
the error is correct caus its owned by root. My Questions is who should own it ? Im not sure how that works, what process/user calls the auth-userdb ? The auth-userdb returns the args generated in master.conf, right ?
i think comment out the user and group setting in master.conf will fix it but im not sure if that is the securest way.
the mails come from postfix via dovecot-lda
Hans
master.conf service auth { # auth_socket_path points to this userdb socket by default. It's typically # used by dovecot-lda, doveadm, possibly imap process, etc. Its default # permissions make it readable only by root, but you may need to relax these # permissions. Users that have access to this socket are able to get a list # of all usernames and get results of everyone's userdb lookups. unix_listener auth-userdb { mode = 0600 #user = vmail #group = vmail }
auth-ldap.conf.ext passdb { driver = ldap args = /etc/dovecot/dovecot-ldap.conf.ext } userdb { driver = static args = uid=vmail gid=vmail home=/home/MAILBOXES/%u/ mail=/home/MAILBOXES/%u/mail }
Had more or less the same fight with 1.2.9. I had to change auth user to the group 'shadow' (if /etc/shadow is owned by group shadow). Or run auth under the default user 'root'.
In your case it has to do with the passdb and/or userdb you use. In my case I had the problems with local users via pam.
HTH Egbert Jan