[Dovecot] permissions on auth-userdb
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 }
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
Op 31-8-2010 2:13, spamvoll@googlemail.com schreef: 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
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
On Tue, 2010-08-31 at 02:13 +0200, spamvoll@googlemail.com wrote:
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)
You're calling dovecot-lda as the user vmail:vmail, probably from your MTA. Probably it's not being called by anyone else.
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
Comment out the user/group lines above and that should work fine.
<spamvoll <at> googlemail.com> writes:
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
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
it ? 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 }
Hi all was getting the same errors took me 2 days to understand what it was saying to me but i finally solved it
if you do an ls -l /var/run/dovecot/auth-userdb you will seet that root is the owner and the premissions are srw-------- so vmail has not right to call or even use the process What i did was a chown -R vmail:vmail /var/run/dovecot/auth-userdb I also did a chmod g+r /var/run/dovecot/auth-userdb ls -l /var/run/dovecot/auth-userdb srw----r-- 1 vmail vmail my unix_listener auth-userdb { mode = 600 {
protocol lda { auth_socket_path = /var/run/dovecot/auth-userdb log_path = /home/vmail/dovecot-deliver.log
that worked for me
- havent restarted the dovecot service dont know if it will keep the settings.
It would be nice if there were a wiki page specifically describing how permissions should be set for all of the services/directories that dovecot uses.
Even better would be a dovecot/doveconf command that would test the permissions and, if possible, even fix them (like the postfix 'set-permissions' command)...
On 2012-06-22 11:46 AM, robert coore <robertcoore@yahoo.com> wrote:
<spamvoll<at> googlemail.com> writes:
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
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
it ? 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 }
Hi all was getting the same errors took me 2 days to understand what it was saying to me but i finally solved it
if you do an ls -l /var/run/dovecot/auth-userdb you will seet that root is the owner and the premissions are srw-------- so vmail has not right to call or even use the process What i did was a chown -R vmail:vmail /var/run/dovecot/auth-userdb I also did a chmod g+r /var/run/dovecot/auth-userdb ls -l /var/run/dovecot/auth-userdb srw----r-- 1 vmail vmail my unix_listener auth-userdb { mode = 600 {
protocol lda { auth_socket_path = /var/run/dovecot/auth-userdb log_path = /home/vmail/dovecot-deliver.log
that worked for me
- havent restarted the dovecot service dont know if it will keep the settings.
--
Best regards,
Charles Marcus I.T. Director Media Brokers International, Inc. 678.514.6200 x224 | 678.514.6299 fax
On 23.6.2012, at 13.34, Charles Marcus wrote:
It would be nice if there were a wiki page specifically describing how permissions should be set for all of the services/directories that dovecot uses.
Even better would be a dovecot/doveconf command that would test the permissions and, if possible, even fix them (like the postfix 'set-permissions' command)...
The problem with those is that it depends on the installation. Each user may need different permissions. Many installations don't have a way to list users to even do a userdb lookup. I guess it would be possible to write such a tool for specific installations where it could work, but it wouldn't work everywhere..
On 2012-06-27 8:29 AM, Timo Sirainen <tss@iki.fi> wrote:
On 23.6.2012, at 13.34, Charles Marcus wrote:
It would be nice if there were a wiki page specifically describing how permissions should be set for all of the services/directories that dovecot uses.
Even better would be a dovecot/doveconf command that would test the permissions and, if possible, even fix them (like the postfix 'set-permissions' command)...
The problem with those is that it depends on the installation. Each user may need different permissions. Many installations don't have a way to list users to even do a userdb lookup. I guess it would be possible to write such a tool for specific installations where it could work, but it wouldn't work everywhere.
Hmmm... I wonder how postfix does it then... maybe it doesn't have as many potential variations I guess?
Is there maybe just a basic/standard set of permissions that can work for many installations, then have a way to detect non-standard installs and just provide a link to a wiki page describing things in more detail?
Is there a wiki page for this already? I didn't find one...
--
Best regards,
Charles
On Wed, 2012-06-27 at 08:34 -0400, Charles Marcus wrote:
On 2012-06-27 8:29 AM, Timo Sirainen <tss@iki.fi> wrote:
On 23.6.2012, at 13.34, Charles Marcus wrote:
It would be nice if there were a wiki page specifically describing how permissions should be set for all of the services/directories that dovecot uses.
Even better would be a dovecot/doveconf command that would test the permissions and, if possible, even fix them (like the postfix 'set-permissions' command)...
The problem with those is that it depends on the installation. Each user may need different permissions. Many installations don't have a way to list users to even do a userdb lookup. I guess it would be possible to write such a tool for specific installations where it could work, but it wouldn't work everywhere.
Hmmm... I wonder how postfix does it then... maybe it doesn't have as many potential variations I guess?
Postfix internally doesn't really use anything except root and postfix users. Dovecot can be configured in many different ways to handle mail users and that configuration affects quite a many settings.
Is there maybe just a basic/standard set of permissions that can work for many installations, then have a way to detect non-standard installs and just provide a link to a wiki page describing things in more detail?
I guess there could be two common settings described: Virtual users with one UID, and system users with multiple UIDs.
Is there a wiki page for this already? I didn't find one...
Maybe something could be written under http://wiki2.dovecot.org/UserIds
participants (5)
-
Charles Marcus
-
Egbert Jan van den Bussche
-
robert coore
-
spamvoll＠googlemail.com
-
Timo Sirainen