dovecot - Aug 2013 - misconception in uid and gid

Hi,

	I'm using a SQL database to store the usernames and passwords of my users.
However, I have found that I must explicitly return the uid and gid with every
query, even though all virtual users use the same uid and gid. The query, that
works, is:

	user_query = SELECT mail, 'vmail' AS uid, 'vmail' AS gid, home,
CONCAT('*:storage=', quota_MB*1024) AS quota_rule \
             FROM virtual_users AS V LEFT JOIN virtual_domains AS D ON
V.domain_id=D.id WHERE V.user='%n' AND D.name='%d'

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?
Regards,

Felix

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 1 Aug 2013, Felix Rubio Dalmau wrote:
> 	I'm using a SQL database to store the usernames and passwords of my
users. However, I have found that I must explicitly return the uid and gid with
every query, even though all virtual users use the same uid and gid. The query,
that works, is:
>
> 	user_query = SELECT mail, 'vmail' AS uid, 'vmail' AS gid,
home, CONCAT('*:storage=', quota_MB*1024) AS quota_rule \
>             FROM virtual_users AS V LEFT JOIN virtual_domains AS D ON
V.domain_id=D.id WHERE V.user='%n' AND D.name='%d'
>
> 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?
Did you posted your setup (aka configuration, dovecot -n) somewhere to 
look at?

You seem to use an elder Dovecot, because newer versions use a more 
descriptive error message, see: 
http://www.dovecot.org/list/dovecot/2012-November/069651.html

Because, first you need to know which socket makes the problem, then you 
can see, if changing the owner helps. This error has nothing to do with 
Unix permission per se, but you can disable Dovecot's access checks when 
you chmod a+x that particular socket.

IMHO, the check itself tests if the querying Unix uid is either the owner 
or group member of the socket or owner of the retrieved record. In a 
single uid-system this check has no meaning - on a dedicated mail system 
at least. Because the global mail_uid has no meaning in the auth code (as 
this is no "default" value), you are left with:

a) return uid with the query _and_ have all users use the same uid,or
b) disable the Dovecot check by changing the socket's Unix permission to 
something different that 0666, e.g. set x-Unix-permission,or
c) change the owner of the socket to vmail (then root cannot access the 
entries, if necessary),or
d) put all Unix users, that access the socket, into one group and have the 
socket owned by that group.

This is the code ./src/auth/auth-master-connection.c:

st contains the data of the socket, cred the data of the accessing user, 
when conn->userdb_restricted_uid is set, later in the code the entries 
owner uid must match that number.


/*!!! at this point variant b) would apply */
         /* figure out what permissions we want to give to this client */
         if ((st->st_mode & 0777) != 0666) {
                 /* permissions were already restricted by the socket
                    permissions. also +x bit indicates that we shouldn't do
                    any permission checks. */
                 return 0;
         }

[snip]

/*!!! at this point variants c) and d) would apply */
         if (cred.uid == st->st_uid || cred.gid == st->st_gid) {
                 /* full permissions */
                 return 0;
         } else {
                 /* restrict permissions: return only lookups whose 
returned
                    uid matches the peer's uid */
                 conn->userdb_restricted_uid = cred.uid;
                 return 0;
         }


- -- 
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBUftX5l3r2wJMiz2NAQLPBgf+M8jdWIjLttu+dl/aIKAmuAGnt8qreBa1
dxfeinqNdzd14ZaJUnF+hjSUeyVdydeuRwhMXXtPoAFdT+S4Uf5AG4yAT6iMqZPX
nalaTMxCCymUuEBxX3K8LvD6iT5cmAdFP0ejTivSiDuOw2i76t0qsfyIi+2e26jd
i46jvEmQxYu6WMtZrUnmjb+5d46BPNL/8hWjNo7yT4sqdMI+GEZO5Osfv+VsqUNd
zoQPDrcoDT+CtMqi4pdEFJbR5QTNppu56Gs0ibNMhSO3NvHleKAy2+jtmx5FyLjk
uvnxjsh9wjGi24UiAXD1knJqiZqrx5J3FTZMDdPQejHmSjGsYPdPCw==RHpW
-----END PGP SIGNATURE-----