Access Control Lists
====================

Dovecot v1.0 and v1.1 supports administrator-configured ACL files. v1.2+
supports also IMAP ACL extension which allows users to change ACLs themselves.
The ACL code was written to allow multiple ACL backends, but currently Dovecot
supports only ACL files. This page talks mainly about how ACLs work, for more
general description of how shared mailboxes work, see<SharedMailboxes.txt>.

ACLs can be enabled in dovecot.conf with:

---%<-------------------------------------------------------------------------
protocol imap {
  mail_plugins = acl
}
protocol lda {
  # If you use deliver with Sieve you may want to enforce ACLs:
  mail_plugins = acl
}

plugin {
  # Without global ACLs:
  acl = vfile

  # With global ACLs in /etc/dovecot/acls/ directory:
  #acl = vfile:/etc/dovecot/acls
}
---%<-------------------------------------------------------------------------

ACL groups are supported since v1.1+ by returning a comma-separated
'acl_groups'<extra field> [UserDatabase.ExtraFields.txt] from userdb, which
contains all the groups the user belongs to. User's UNIX groups have no effect
on ACLs.

The default ACL for mailboxes is to give the mailbox owner all permissions and
other users none. Mailboxes in public namespaces don't have owners, so by
default no-one can access them.

ACL vfile backend
-----------------

vfile backend supports per-mailbox ACLs and global ACLs.

Per-mailbox ACLs are stored in 'dovecot-acl' named file, which exists in:

 * maildir: The maildir's root directory (eg. '~/Maildir',
   '~/Maildir/.folder/')
 * mbox: Currently in the same directory as indexes (eg.
   '~/mail/.imap/INBOX/'), but this might change
 * dbox: dbox's root directory (eg. '~/dbox/INBOX/dbox-Mails/')

Currently there is no ACL inheritance. It's not possible to specify that
"mailbox and all its children have these ACLs". The ACLs have to be explicitly
specified for each created mailbox. Although instead of copying the dovecot-acl
files you could instead create symlinks.

Global ACLs
-----------

Global ACLs are used mainly for two purposes:

 1. Removing some permissions from users' personal mailboxes. For example each
    user might have an "Invoices" mailbox which will be read-only.
 2. Giving permissions to master user logins. Master user is not the mailbox
    owner, so by default it has no permissions to any of the mailboxes.

Global ACL directory is specified as a parameter to vfile backend in 'acl'
setting ('/etc/dovecot/acls/' in the above example). They are looked up using
the mailbox's real name. For example:

 * INBOX: '/etc/dovecot/acls/INBOX'
 * archives.2007: '/etc/dovecot/acls/archives.2007'
 * archives/2007: '/etc/dovecot/acls/archives/2007'

The mailbox names are looked up using the real separators, not the virtual ones
that can be configured in namespaces. So even if you specify 'separator=/' with
Maildir, the ACL files still use the '.' separator, just as the Maildir
directory names are also stored using '.'. There is no leading '.' however.

There is an extra problem with mailbox formats that use '/' as the separator
(e.g. mbox, dbox): For example if you have mailboxes "foo" and "foo/bar" and
you wish to give ACLs to both of them, you can't create both
'/etc/dovecot/acls/foo' and '/etc/dovecot/acls/foo/bar' files. The 'foo' has to
be either a directory or a file, it can't be both. To solve this problem, you
can instead create a .DEFAULT file for "foo":

 * foo: '/etc/dovecot/acls/foo/.DEFAULT'
 * foo/bar: '/etc/dovecot/acls/foo/bar'

WARNING: With v1.0 namespace prefixes are ignored, so if you have multiple
namespaces their mailbox names could conflict. With v1.1 you must use the
namespace prefixes. For example with namespace 'prefix=INBOX/' containing
mailbox "foo" use '/etc/dovecot/acls/INBOX/foo'.

If a mailbox has both global and per-mailbox ACL file, both of them are read
and the ACLs are merged. If there are any conflicts:

 * v1.0 and v1.1: The per-mailbox ACL file overrides global ACL file.
 * v1.2+: The global ACL file overrides per-mailbox ACL file. This change was
   done because in v1.2+ users can modify their own per-mailbox ACL files via
   IMAP ACL extension. Global ACLs can only be modified by administrator, so
   users shouldn't be able to override them.

ACL files
---------

The files themselves are in format:

---%<-------------------------------------------------------------------------
<identifier> <ACLs> [:<named ACLs>]
---%<-------------------------------------------------------------------------

Where *identifier* is one of:

 * group-override=*group name*
 * user=*user name*
 * owner
 * group=*group name*
 * owner
 * authenticated
 * anyone / anonymous

The ACLS are processed in the order given above, so for example if you have
given read-access to a group, you can still remove that from specific users
inside the group.

Group-override identifier allows you to override users' ACLs. Probably the most
useful reason to do this is to temporarily disable access for some users. For
example:

---%<-------------------------------------------------------------------------
user=timo rw
group-override=tempdisabled
---%<-------------------------------------------------------------------------

Now if /timo/ is in /tempdisabled/ group, he has no access to the mailbox. This
wouldn't be possible with a normal group identifier, because the 'user=timo'
would override it.

The currently supported ACLs and their corresponding named ACLs are: 

+---+---------------+---------------------------------------------------------+
| l | lookup        | Mailbox is visible in mailbox list. Mailbox can be      |
|   |               | subscribed to.                                          |
+---+---------------+---------------------------------------------------------+
| r | read          | Mailbox can be opened for reading.                      |
+---+---------------+---------------------------------------------------------+
| w | write         | Message flags and keywords can be changed, except \Seen |
|   |               | and \Deleted                                            |
+---+---------------+---------------------------------------------------------+
| s | write-seen    | \Seen flag can be changed                               |
+---+---------------+---------------------------------------------------------+
| t | write-deleted | \Deleted flag can be changed                            |
+---+---------------+---------------------------------------------------------+
| i | insert        | Messages can be written or copied to the mailbox        |
+---+---------------+---------------------------------------------------------+
| e | expunge       | Messages can be expunged                                |
+---+---------------+---------------------------------------------------------+
| k | create        | Mailboxes can be created under this mailbox             |
+---+---------------+---------------------------------------------------------+
| x | delete        | Mailbox can be deleted                                  |
+---+---------------+---------------------------------------------------------+
| a | admin         | Administration rights to the mailbox                    |
+---+---------------+---------------------------------------------------------+

The ACLs are compatible with RFC 4314 (IMAP ACL extension, updated version).

Unknown ACL letters are complained about, but unknown named ACLs are ignored.
Named ACLs are mostly intended for future extensions.

Example ACL file:

---%<-------------------------------------------------------------------------
owner lrwstiekxa
user=timo rl
---%<-------------------------------------------------------------------------

(This file was created from the wiki on 2009-03-02 04:42)
