[Dovecot] master user and ACL's

[Timo Sirainen]

On 13.2.2014, at 16.37, Peter Mogensen <apm at one.com> wrote:

> On 2014-02-13 04:40, Timo Sirainen wrote:
>> On 9.2.2014, at 17.36, Peter Mogensen <apm at one.com> wrote:
>>> 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?
>> 
>> 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.
> 
> 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.

Very inefficient when there are millions of users.

>> 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.

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.)