Dovecot 2 - ACL

Вторник, 1 апреля 2014 г.

В заметке переведена часть документации Dovecot 2 по ACL. Перевод вольный + отсебятина. Представление об ACL, о разных формах прав. Формат директив-символов в файлах ACL. ACL для мастер-пользователя и пр.

ВАЖНО! Эта страница является частью списка заметок о настройке почтовой системы (Postfix+Dovecot и пр.).
Родительская страница - обязательна к просмотру: Установка и настройка почтового сервера

Подробнее о конфигурации к которой относятся примеры в этой статье - см. ссылку выше.
Тем же - коротко об основных терминах (MTA, MDA, MUA и т.п.).

Эта заметка имеет характер исследования. Все упомянутые в заметке эксперименты проводились на ОС Debian. Пожалуйста не используйте слепое копирование примеров. Автор не гарантирует, что применение изложенной здесь информации не приведет к потере данных.

Это скорее конспект-шпаргалка, чем достоверный справочник. Кроме ответов здесь могут присутствовать вопросы.

Это вольный перевод, без предупреждений разбавленный отсебятиной!

Под ящиком здесь подразумевается корневой почтовый каталог пользователя, включающий все вложенные папки. Каталоги/папки пользователя расположены в пределах почтового ящика.

ACL

Начиная с версии Dovecot 1.2+, поддерживается расширение IMAP-ACL, позволяющее пользователям самим настраивать списки контроля доступа. В настоящее время (Dovecot 2.1.7) поддерживается ACL только для виртуальных пользователей. ACL не дает пользователям ящиков дополнительные права как системным пользователям на уровне файловой системы. Необходимо убедится что процессы имеют достаточно прав, для доступа к почтовым ящикам.

Включение ACL (пример из официальной документации изменен - разделено на два файла):

Файл /etc/dovecot/conf.d/20-imap.conf

protocol imap {
  mail_plugins = $mail_plugins imap_acl
}

Файл /etc/dovecot/conf.d/90-acl.conf

plugin {
  # Without global ACLs:
  acl = vfile
  # With global ACLs in /etc/dovecot/acls/ directory:
  #acl = vfile:/etc/dovecot/acls
}

Примеры скопированы из официальной документации. В рассматриваемой конфигурации это выглядят по-другому!

Группы ACL можно получать посредством использования экстра-поля acl_groups во время запроса данных пользователя через userdb (например с использованием SQL, хотя в стандартной установке PostfixAdmin такие столбцы не предусмотрены). Запрос должен возвращать значения через запятую. По видимому можно использовать тот же механизм и во время выполнения запроса passdb, но с учетом префикса "userdb_": userdb_acl_groups ^{{информация требует проверки и уточнения}}.
См. также заметку - Dovecot 2 - описание настроек, в контексте рассматриваемой конфигурации.

По умолчанию устанавливаются все разрешения для владельца ящика, и никаких разрешений - для других пользователей. Публичные ящики по умолчанию не имеют владельца, поэтому никто не может получить к ним доступ.

ACL vfile бакэнд

Для глобальных ACL и ACL каждого ящика поддерживается vfile-бакэнд (vfile - virtual file).

Для каждого ящика ACL хранится в файле dovecot-acl , который находится:

Maildir: почтовый каталог владельца ящика (например ~/Maildir, ~/Maildir/.folder/)
MailBox: Контролируемый каталог. Нужно явно указать расположение почты :CONTROL=<path>
Dbox: Каталог почты Dbox (например ~/dbox/INBOX/dbox-Mails/)

КСТАТИ! RoundCube имеет плагин "acl", при подключении которого, в настройках появляется дополнительная вкладка "Совместный доступ" у свойств любой папки.

Наследуемый ACL

Каждый раз, когда создается новый подкаталог, он получает свой ACL от родительского каталога. Во время создания родительского корневого каталога, ему назначается ACL по умолчанию из namespace. Полноценное наследование не поддерживается! "Наследование" происходит только в момент создания подчиненного каталога. Если параметры ACL родительского каталога были изменены уже после создания подчиненного каталога, то в подчиненном каталоге останется всё по-старому.

ACL переносится из namespace по умолчанию из файла dovecot-acl корневого каталога (например: /var/public/Maildir ). Это происходит только при создании новых каталогов, и не касается каталогов, которые уже были созданы ранее без поддержки ACL.

Глобальный ACL

Глобальный ACL, в отличие от наследуемого ACL, применяется всегда и для всех пользователей.
Типичные цели его использования:

Удаление некоторых разрешений из личных папок пользователей. Например каждый пользователь может иметь сообщения "Счета", которые будут доступны ему только для чтения.
Дополнительный допуск для мастер-пользователя. Мастер-пользователь не имеет своего почтового ящика, поэтому по умолчанию он вообще не имеет никаких разрешений. Добавление разрешений для него осуществляется в глобальном ACL. См. ниже - подробнее о мастер-пользователе.

Каталог глобальных ACL задается с помощью параметра vfile . например: /etc/dovecot/acls/ (см. выше). ACL должны выглядеть, как реальное имя каталога ящика. Например:

для INBOX: /etc/dovecot/acls/INBOX
для archives.2007: /etc/dovecot/acls/archives.2007
для archives/2007: /etc/dovecot/acls/archives/2007

Имена каталогов просматриваются с реальным разделителем, а не виртуальным как в namespace. Таким образом, даже если для Maildir указан разделитель "/" (separator=/ ), ACL будут сопоставлены каталогам с таким разделителем, который присутствует в реальных именах каталогов (напр "."). Хотя в именах ACL не будет "."

Важно! Здесь в официальной документации смысл сказанного может сбить с толку. Поэтому позволю себе одно явное уточнение. Достоверно проверено, что, например, для папки .../domain.tld/user/.Sent/ , глобальный ACL-файл должен быть таким: /etc/dovecot/acls/domain.tld/Sent - без точки! Остальные файлы глобальных ACL так-же должны быть без точки!

Существует дополнительная проблема с форматами ящиков, которые используют "/" в качестве разделителя каталогов (например, Mbox, Dbox). Например, если для каталогов "foo" и "foo/bar" необходимо назначить разные ACL, то нельзя использовать файлы /etc/dovecot/acls/foo и /etc/dovecot/acls/foo/bar .
"foo" - должен быть либо каталогом, либо файлом. Он не может быть и тем, и другим. Для решения этой проблемы можно создать файл по умолчанию для "foo":

файл ACL для foo: /etc/dovecot/acls/foo/.DEFAULT
файл ACL для foo/bar: /etc/dovecot/acls/foo/bar

Имена файлов должны начинаться с префикса (если он есть) namespace. Например, если в namespace используется префикс prefix=INBOX/ , то для каталога "foo" нужно использовать ACL-файл /etc/dovecot/acls/INBOX/foo .

Глобальный и частный ACL для одного каталога - объединяются. Если же в глобальном и частном ACL присутствуют взаимоисключающие правила для каталога, то приоритетным считается правило глобального ACL, а правило частного ACL в таком случае - игнорируется. Это сделано для того, чтобы пользователи не могли (например через расширение IMAP-ACL, которое дает возможность пользователям создавать свои правила) переопределить глобальные ACL, назначаемые администратором.

А теперь примеры для рассматриваемой в этой серии заметок конфигурации:

Для создания глобального ACL нужно указать путь vfile в конфиге /etc/dovecot/conf.d/90-acl.conf :

plugin {
  acl = vfile:/etc/dovecot/acls/%d:cache_secs=300
}

Параметр :cache_secs=300 определяет сколько времени должно пройти, чтобы были видны изменения. Рестартить Dovecot для применения изменений не требуется.

Эта запись указывает, что для каждого домена информация о глобальных правилах будет искаться в папке, имя которой должно совпадать с именем домена (/etc/dovecot/acls/%d ).

Для рассматриваемой здесь конфигурации - внутри этой папки можно создать файл "INBOX" в котором указать какие-нибудь правила. При этом "INBOX" - виртуальный указатель. Папки "INBOX" не существует, - физической корневой папкой "Входящие" для каждого пользователя является корневая папка его ящика с именем пользователя без доменной части.

Несмотря на то, что в рассматриваемом в этих заметках частном случае конфигурации, остальные папки являются вложенными, а "INBOX" является корневой, правила "INBOX" применяться ко всем остальным папкам личных ящиков (Sent, Drafts и т.п.) не будут. Т.е. для каждой папки нужно создать свой ACL-файл.

Либо создать файл .DEFAULT, в котором прописать ACL для всех папок.
Например /etc/dovecot/acls/domain.tld/.DEFAULT :

owner lrwstipexa

Здесь, в этом примере, для владельца любой папки пользователя указанного домена разрешено всё, кроме создания подкаталогов. Подробнее о символах-директивах - см. следующий раздел.

Формат директив в файлах ACL

Внутренний формат директив в файлах ACL такой:
<identifier> <ACLs> [:<named ACLs>] ,

где <identifier> может быть одним из:

group-override=group name
user=user name
owner
group=group name
authenticated
anyone (или anonymous, который является алиасом для anyone)

Списки ACL обрабатываются в порядке уменьшения приоритета, в очередности указанной выше (т.е. в приведенном списке не просто перечисены идентификаторы, а показан их приоритет по отношению друг к другу, например "group-override" имеет наиболее высокий приоритет и может отменять/переопределять те идентификаторы, которые ниже в этом списке).

Например можно дать всей группе доступ на чтение, и тут же запретить этот доступ отдельным пользователям этой группы (отменить уже назначенное правило группы для отдельных ее участников). Это возможно потому, что идентификатор "user", как мы видим в этом списке, указан выше идентификатора "group".

Еще пример. Используя самый приоритетный идентификатор - "group-override", можно переопределить ACL, назначенные для юзеров. Причиной для этого может стать, например необходимость отключить доступ для некоторых пользователей.

Например:

user=timo rw
group-override=tempdisabled

Теперь можно включить пользователя "timo" в группу "tempdisabled", для которой назначить запрет доступа к почтовым ящикам. В результате, для пользователя "timo" доступ к ящику будет закрыт. Это было бы не возможно, если бы для запрета использовался идентификатор "group", поскольку, как следует из этого списка, идентификатор "user" указан выше идентификатора "group", соответственно, он - приоритетнее. Но идентификатор "group-override" приоритетнее чем "user", и, используя именно его, можно решать задачу. См. о группах выше.

Допустимые директивы в ACL:

l	lookup	Каталог отображается в списке. Каталог может быть "подписан" (доступен в MUA через IMAP).
r	read	Каталог доступен для чтения.
w	write	Флаги и ключи для писем могут быть изменены, за исключением "\Seen" и "\Deleted"
s	write-seen	Флаг "\Seen" может быть изменен.
t	write-deleted	Флаг "\Deleted" может быть изменен.
i	insert	В каталог можно записывать или копировать письма.
p	post	Доставка сообщений (писем) в каталог разрешена для LDA. Например посредством Sieve-скриптов.
e	expunge	Сообщения можно стирать.
k	create	В каталоге могут быть созданы/переименованы вложенные подкаталоги. Но возможность создавать в этих подкаталогах другие подкаталоги регулируется наследуемой ACL. Возможность переименования так же определяется зависимостью от возможности удаления.
x	delete	Каталог разрешено удалить.
a	admin	Административные права для каталога. В данный момент имеется возможность разрешить изменять ACL каталога.

Эти ACL совместимы с RFC 4314 (для расширения IMAP-ACL обновленной версии).

Неизвестные ACL-символы игнорируются, но допускаются для использования в будущих версиях.

Пример файла ACL:

owner lrwstipekxa
user=timo rl

Первая строка говорит о том, что владельцу можно всё. Вторая строка говорит о том, что кроме владельца доступ на чтение и просмотр имеет пользователь "timo".

Файл dovecot-acl-list

Все каталоги, которые будут перечислены в файле dovecot-acl-list получают символ-директиву "l". Если будет использоваться файл dovecot-acl , то файл dovecot-acl-list по-видимому следует удалить.

ACL для мастер-пользователя

В ACL мастер-пользователь подчиняется тем же правилам, что и обычные пользователи, имеющие свои ящики. Поэтому, если не указать для него разрешений явно, он не будет иметь доступа ни к одному ящику/каталогу.

Дать особые полномочия мастер-пользователю можно следующим образом:

Добавить глобальный ACL для данного пользователя. К сожалению, в настоящее время (Dovecot 2.1.7) можно указывать ACL только для явно определенных каталогов. Нет возможности установить права для "всех каталогов в по умолчанию".
Определить MASTER_USER=$USER в postlogin-script. В результате этого в ACL вместо логина мастер-пользователя будет использован логин реального пользователя.
Использовать master_user=%u при выполнении запроса "userdb", во время поиска данных пользователя. Эффект от этого метода будет такой-же, как при использовании postlogin-script.

Источники

Источники информации и ссылки перечислены на отдельной странице, указанной внизу главной страницы темы:
Установка и настройка почтового сервера