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