On 13.2.2014, at 16.37, Peter Mogensen <a...@one.com> wrote: > On 2014-02-13 04:40, Timo Sirainen wrote: >> On 9.2.2014, at 17.36, Peter Mogensen <a...@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.)
