[Dovecot] misconception in uid and gid

[Felix Rubio Dalmau]

Hi everybody,

	I have pasted my configuration in http://snipt.org/AThd4

	Then, I understand that the easiest to do is to change the permissions of  the socket but... which socket?? Additionally, userdb-auth is showing permissions srw-rw-rw-

	Regards!
	Felix


On Friday 02 August 2013 08:55:33 you wrote:
> 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
>