Проблемы с разрешениями при подключении к NFS / var / spool / mail для dovecot и procmail

Настройка моего почтового сервера работала годами. Недавно я столкнулся со следующей проблемой:

Настройка почты: sendmail + dovecot + procmail

Хост-файловый сервер: CentOS 6.8, NFS экспортирует почтовые каталоги в ...

Почтовый сервер: CentOS 7.3, работающий как гостевая виртуальная машина на хосте через libvirtd / qemu, NFS монтирует / var / spool / mail с хоста.

Симптомы: и dovecot, и procmail выдали ошибки (подробности ниже), которые, похоже, указывают на то, что у них нет разрешения на запись в / var / spool / mail. Однако / var / spool / mail имеет самые общие разрешения, которые я знаю, как давать как на файловом сервере NFS, так и на почтовом клиенте NFS.

На почтовом сервере (клиент NFS):

 $ ls -lhd /var/spool/mail
 drwxrwxrwt 5 root mail 6.8M Mar 29 12:37 /var/spool/mail

На почтовом сервере: / etc / fstab:

 filehost:/mail/inbox      /var/spool/mail         nfs     defaults        0 0

На хосте NFS:

 $ ls -lhd /mail/inbox
 drwxrwxrwt. 5 root mail 6.8M Mar 29 12:41 /mail/inbox

В filehost: / etc / exports:

 /mail/inbox          mailserver(rw,no_root_squash,async,nohide)

Ни одна из систем не работает под управлением SELinux или iptables (я полагаюсь на брандмауэр нашего сайта).

Что я вижу:

• Файлы с именами типа BOGUS.normaluser.hex-string. Соответствующее сообщение журнала

  29 марта 12:14:34 почтовый сервер procmail [20922]: поддельный "/var/spool/mail/normaluser.lock" переименован в "/var/spool/mail/BOGUS.normaluser.xGAs"

  Это может сильно раздражать, поскольку бывали случаи, когда поддельным объявлялся не только файл блокировки, но и почтовый ящик обычного пользователя. С точки зрения обычного пользователя, их почтовый ящик исчезает, когда они читают свою почту.

• Файлы с именами, начинающимися с подчеркивания, например, _2-E, eu92YB.mailserver.domain.

  Нет соответствующих сообщений журнала. Содержимое этих файлов (которые всегда имеют размер 1 или 31-33 байта) предполагает, что это файлы блокировки. На веб-странице, которую я видел вчера, описывалось, что кто-то использовал strace для определения того, что procmail записывает эти файлы, но я не знаю, как использовать strace, чтобы подтвердить это для себя (и я не могу найти страницу сегодня).

  Когда я перечисляю файлы, я вижу, что это chmod 400, возможно, поэтому они не удаляются:

-r-------- 1 normaluser    mail 1 Mar 29 12:30 _uZF%kE-2YB.mailserver.domain
-r-------- 1 normaluser    mail 1 Mar 29 12:30 _uZF+kE-2YB.mailserver.domain
-r-------- 1 normaluser    mail 1 Mar 29 12:31 _uZF,kF-2YB.mailserver.domain
-r-------- 1 normaluser    mail 1 Mar 29 12:31 _uZF.kF-2YB.mailserver.domain
-r-------- 1 normaluser    mail 1 Mar 29 12:31 _uZF+kF-2YB.mailserver.domain

• Файлы блокировки, которые не исчезают. Типичная запись в почтовом журнале:

Mar 29 12:31:01 mailserver dovecot: imap(normaluser): Error: unlink(/var/spool/mail/normaluser.lock) failed: Operation not permitted

Mar 29 12:31:01 mailserver dovecot: imap(normaluser): Error: file_dotlock_create() failed with mbox file /var/spool/mail/normaluser: Operation not permitted

Для пользователей не удаляемый файл блокировки означает, что вся их обработка почты останавливается, пока я вручную не удалю файл блокировки. Разрешения кажутся нормальными:

-rw------- 1 normaluser    theirgroup 33 Mar 29 12:30 normaluser.lock

Я немного поигрался с вариантами голубятни, основанными на вики-сайте dovecot, надеясь, что где-то ошибся. Текущие соответствующие значения:

 mmap_disable = yes
 dotlock_use_excl = yes
 mail_fsync = optimized
 mail_nfs_storage = no
 mail_nfs_index = no
 mail_privileged_group=mail

Установка mail_nfs_storage = yes, похоже, ничего не меняет, поскольку этот параметр (согласно вики dovecot) имеет отношение к нескольким почтовым серверам, обращающимся к одному и тому же каталогу через NFS, что здесь не так.

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

Потом:

Я приближаюсь к решению. На почтовом сервере клиента:

 $ cd /var/spool/mail
 $ sudo -u normaluser touch test
 $ sudo -u normaluser rm test

Нет проблем.

 $ sudo -u dovenull touch test
 $ sudo -u dovenull rm test
 rm: cannot remove ‘test’: Operation not permitted
 $ ls -lh test
 -rw-r--r-- 1 nobody nobody 0 Mar 31 12:03 test

Ага! Учетной записи dovenull не разрешено ничего делать в каталоге, импортированном по NFS. Я попытался добавить учетную запись dovenull на сервер NFS (с тем же uid / gid), но это не решило проблему:

 $ sudo -u dovenull rm test
 rm: cannot remove ‘test’: Operation not permitted
 $ ls -lh test
 -rw-r--r-- 1 dovenull dovenull 0 Mar 31 12:03 test

Это похоже на проблему с idmap. Вот единственные раскомментированные строки в idmap.conf как на клиенте, так и на сервере:

[General]
Domain = mydomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
[Translation]
Method = nsswitch

Я близко ... Я чувствую это ...

Еще позже:

Я чувствую все, что хочу, но это не значит, что у меня есть ответ. Я получил учетную запись dovenull, чтобы иметь возможность как создавать, так и удалять в / var / spool / mail (это было связано с внимательным просмотром /etc/nssswitch.conf и пониманием, что мне нужно перезапустить NIS), но это не решило мою проблему. проблема. Учетная запись dovenull не пишет в / var / spool / mail.

Я использовал auditctl:

auditctl -w /var/spool/mail -p war -k mail-inbox
ausearch -k mail-inbox > mail-inbox.txt

и проверил, что дополнительные файлы .lock и BOGUS были созданы dovecot, а файлы подчеркивания "_" были созданы procmail. Я не буду утруждать себя публикацией журналов аудита, если кто-то не хочет их видеть; они показывают, что файлы создаются с правильными разрешениями (uid, gid, euid и т. д.), а удаления неуспешны, даже если вызов удаления выполняется с теми же разрешениями.

Так что же могло вызвать создание файла, но невозможность его удаления?