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
