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