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.