[Dovecot] Preparing for sharing with ACLs
Greetings -
I'm finalising the layout of our new mailstore ready for a trial
service using Dovecot (switching from the UW IMAP server). This is
using Maildir mailboxes, changing from our current mix of MBX and
traditional Berkeley.
One of the things we are often asked for is how someone can grant
another access to their mailbox: eg, a Head of Department wants the
Departmental Secretary to review and reply to e-mails, but not tell
her the password.
I understand that Dovecot doesn't provide a user-interface for
setting up or manipulating these, nor the IMAP ACL extension at this
time, so...
Q1. Are there plans to add support for ACLs in the future, along
with an
end-user accessible means of setting these up and manipulating
them?
I also understand that it is currently possible for the Mail Admin to
set up ACLs (globally and/or per-mailbox) and shared folders (I admit
I'm having trouble getting my head around the latter in the Wiki a bit).
I' hoping to avoid using the current "has to be done by the
Administrator" setup, and instead want to plan for any future end-
user interface.
We are using filestore quotas for the Maildirs, so at present a
user's Maildir directories and files are owned by their username
(UNIX uid) and group (UNIX gid).
- Naturally for filestore quotas to continue to work items need to continue to be owned by the person's username (UNIX uid).
When end-user support for shared mailboxes and ACLs comes along one
day (hopefully!) I assume two levels of access control are needed:
At the filestore level the other authorised users will need read and/or write access to the directories and files comprising the Maildir, and
Suitable ACLs will be needed to grant access via Dovecot to
authorised persons, but not to other random people.
So looking to the future, I'm therefore thinking that instead of
having each user's Maildir directories and files owned by their UNIX
uid and gid I should instead have them owned by their UNIX uid and a
common-to-everyone UNIX gid. Eg,
drwxrwx--- user1:mail directoryname
-rw-rw---- user1:mail filename
I realise there is an element of risk here, as we would be relying on
Dovecot's security to limit access so that only authorised users can
access a given person's mailbox.
Is this the right approach to adopt?
Or is there a better way of (one day) enabling Person A to share
their mailbox to Person B but not Person C?
(We need a solution that is general and based on ACLs, not one that
relies on our creating custom UNIX groups and assigning people's
usernames to these.)
I've read the Wiki pages on ACLs and Shared Folders, but am having
trouble putting the information together in my mind to (one day)
solve this particular requirement. Can anyone shed any light, please?
Cheers, Mike B-)
-- The Computing Service, University of York, Heslington, York Yo10 5DD, UK Tel:+44-1904-433811 FAX:+44-1904-433740
- Unsolicited commercial e-mail is NOT welcome at this e-mail address. *
On 22.3.2007, at 12.33, Mike Brudenell wrote:
Q1. Are there plans to add support for ACLs in the future, along
with an end-user accessible means of setting these up and manipulating
them?
Sure, in the future. :)
We are using filestore quotas for the Maildirs, so at present a
user's Maildir directories and files are owned by their username
(UNIX uid) and group (UNIX gid).
Just a reminder that control files can be problematic. http:// wiki.dovecot.org/Quota/FS
So looking to the future, I'm therefore thinking that instead of
having each user's Maildir directories and files owned by their
UNIX uid and gid I should instead have them owned by their UNIX uid
and a common-to-everyone UNIX gid. Eg,drwxrwx--- user1:mail directoryname -rw-rw---- user1:mail filename
I realise there is an element of risk here, as we would be relying
on Dovecot's security to limit access so that only authorised users
can access a given person's mailbox.Is this the right approach to adopt? Or is there a better way of (one day) enabling Person A to share
their mailbox to Person B but not Person C?
I was thinking that the ACL plugin could some day be able to
automatically figure out what would be the group containing the
minimum set of users who can access the mailbox. If everything else
fails, then use the "mail" group or something which contains everyone.
(We need a solution that is general and based on ACLs, not one that
relies on our creating custom UNIX groups and assigning people's
usernames to these.)
If you don't want to create any kind of groups (like "administrative
people", "students", etc.) then I guess the mail group is the only
possibility. But don't give the users directly access to the mail
group, just set Dovecot's mail_extra_groups = mail setting.
participants (2)
-
Mike Brudenell
-
Timo Sirainen