On 2014-02-14 05:49, Timo Sirainen wrote:
Sounds like you don't want the master user to be special in any way now or in
future. In that case setting master_user=%u would do exactly that now and
always. (There might be some other features besides ACLs that could work
differently for master user logins in future.)
It's not that can't think of the need for a "master user", but I think
of SASL authz-id in more general terms. - not a something only used for
"master users".
And actually... the GSSAPI mech in Dovecot already works that way.
The authz-id is looked up in the passdb and the authn-id (the principal)
is matched against the "k5principals" (*) extra-field - not against the
master user database.
A more general way would be to generalize the whole "userok()" check
into a plugable step between passdb lookup and userdb lookup, which
tested whether the SASL authz-id request was ok - (and maybe if it was
ok because it was a master user, or just because local authorization
allowed that)
/Peter
*: Btw... "k5principals" is miss-written in the wiki docs as
"k5credentials". But haven't been able to change it.
