Re: [Dovecot] dovecot Digest, Vol 124, Issue 4
Hello Axel,
but then I don't get it: I thought that "uid" and "gid" in the user_query where used to access the local FS, whereas the "unix_listener auth-userdb" are used to indicate under which owner/group must be auth-userdb run... although maybe I'm wrong :-S :-)
What I'm looking forward to is to eliminate the need for returning these two fixed items, as long as all the virtual_users will be using the same uid and gid.
Does anybody know how can I do it??
Regards, and thank you!
FelixDate: Thu, 1 Aug 2013 17:50:33 +0200 From: Axel Luttgens <AxelLuttgens@swing.be> To: Dovecot Mailing List <dovecot@dovecot.org> Subject: Re: [Dovecot] misconception in uid and gid Message-ID: <89AC3212-EFE6-41E5-A22D-97DC8E771218@swing.be> Content-Type: text/plain; charset=iso-8859-1
Le 1 ao?t 2013 ? 15:43, Felix Rubio Dalmau a ?crit :
[...]
Nevertheless, if I remove the segments "'vmail' AS uid, 'vmail' AS gid" and modify the file conf.d/10-mail.conf to show
mail_uid = vmail mail_gid = vmail
I get this error:
dovecot: auth: Error: userdb(<mail>): client doesn't have lookup permissions for this user: userdb reply doesn't contain uid (change userdb socket permissions)
Does anybody know what is wrong in my set-up?
Hello Felix,
Yes and no... This still remains a bit unclear to me, but you could try something like this:
service auth {
unix_listener auth-userdb { # default: user = $default_internal_user group = vmail # default: group = mode = 0660 # default: mode = 0666 }}
The code has some provisions to avoid the auth-userdb to be too widely open, in spite of that default mode 0666. Changing that mode short-circuits those provisions, and the above is the most secure setting I could think of in the case of a single uid/gid setup.
HTH, Axel
Le 2 août 2013 à 07:43, Felix Rubio Dalmau a écrit :
Hello Axel,
but then I don't get it: I thought that "uid" and "gid" in the user_query where used to access the local FS, whereas the "unix_listener auth-userdb" are used to indicate under which owner/group must be auth-userdb run... although maybe I'm wrong :-S :-)
A service process may indeed be told to run as a given user/group; that service may listen to sockets whose reachability may be configured too, with similar keywords; for
service someservice {
user = ...
group = ...
unix_listener somepath {
user = ...
group = ...
mode = ...
}
}In the case of auth, one has by default for the service and its auth-userdb socket:
service auth {
user = dovecot
group = wheel
unix_listener auth-userdb {
user = dovecot
group = wheel
mode = O666
}
}Taken literally, those defaults mean that everyone may, without restrictions, read from and write to auth-userdb, and thus "speak" with service auth for userdb matters. This is indeed potentially needed, but would be too permissive without some cautions enforced by auth, hence the kind of errors you are facing:
auth: Error: userdb(<mail>): client doesn't have lookup permissions for this user: userdb reply doesn't contain uid (change userdb socket permissions)What I'm looking forward to is to eliminate the need for returning these two fixed items, as long as all the virtual_users will be using the same uid and gid.
Since your mail users are all running as vmail/vmail, I suggested to override the defaults for the auth-userdb socket:
service auth {
unix_listener auth-userdb {
group = vmail
mode = O660
}
}Having a non-default mode for the socket tells auth not to perform its usual checks; it's then up to the admin to devise some sufficiently secure setup.
HTH, Axel
participants (2)
-
Axel Luttgens
-
Felix Rubio Dalmau