[Dovecot] master user and ACL's
Hi,
Quick question...I read in the docs that: "Master user is still subject to ACLs just like any other user, which means that by default the master user has no access to any mailboxes of the user." ... and that the standard workaround is to return master_user=%u from the userdb.
But why is the master_user authn-id used in the ACLs and not the authz-id (requested-login-user) ?
Isn't the whole point of SASL authz-id semantics to have authorization resolved based on the authz-id?
/Peter
On 9.2.2014, at 17.36, Peter Mogensen <apm@one.com> wrote:
Some people are using master user logins to do other types of things, such as allowing voicemail software to access only the Voicemail folder of everyone. Or spam software access only to the Spam folder. Or an alternative read-only username+password for all users that can access the same user's mails only read-only.
On 2014-02-13 04:40, Timo Sirainen wrote:
But wouldn't the correct way for these use cases be to share the individual folders with the voicemail/spam user ACL needed - not to log in as the user.
Or an alternative read-only username+password for all users that can access the same user's mails only read-only.
This one is more tricky, since it mixes authentication and authorization more. ... which always needs thinking in a protocol as IMAP where the resource accessed is tied to the user (as opposed to HTTP).
Intuitively, if I would set this up, I would probably try with having 2 userdb entries pointing to the same mail_location, but with different acl_groups userdb fields. ... or something to that effect. In other words ... not determine it based on authentication-ID, but based on authorization-ID.
My own use-case is to have 1 authentication-ID being able to access several userdb accounts. - with the same credentials. Based on checking whether the give SASL authz-id is OK for that user. But from then on, just be that user.
Is specifying master_user=%u the official way to switch between these behaviours of which SASL id ACLs are checked against or is there an enhancement of the dovecot functionality to consider to handle SASL authz-id/authn-id in a more general way?
/Peter
On 13.2.2014, at 16.37, Peter Mogensen <apm@one.com> wrote:
Very inefficient when there are millions of users.
acl_user userdb field might be useful I guess.
My own use-case is to have 1 authentication-ID being able to access several userdb accounts. - with the same credentials. Based on checking whether the give SASL authz-id is OK for that user. But from then on, just be that user.
Is specifying master_user=%u the official way to switch between these behaviours of which SASL id ACLs are checked against or is there an enhancement of the dovecot functionality to consider to handle SASL authz-id/authn-id in a more general way?
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.)
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.
participants (2)
-
Peter Mogensen
-
Timo Sirainen