Процедура установки Postfix создала системного пользователя postfixи его основную группу, postfixтогда как процедура установки OpenDKIM создала системного пользователя opendkimи его основную группу opendkim.
Чтобы обеспечить совместную работу Postfix и OpenDKIM, большинство администраторов выполняют две операции:
А
Они добавляют вторичную группу opendkimк Postfix.
Б
Они настраивают файл конфигурации OpenDKIM /etc/opendkim.confдля создания сокета UNIX с помощью следующих трех (двух) строк:
UMask 002
PidFile /var/run/opendkim/opendkim.pid
Socket local:/var/spool/postfix/opendkim/opendkim.sock
Официальная документация OpenDKIM гласит следующее для параметра конфигурации UMask:
Запрашивает определенную маску разрешений, которая будет использоваться для создания файла. Это действительно применимо только к созданию сокета, когда Socket указывает сокет домена UNIX, и к PidFile (если таковой имеется);
Я знаю, что сокеты UNIX удобны, поскольку они могут ограничивать привилегии пользователя. В моем случае я хочу, чтобы OpenDKIM работал с Postfix максимально безопасно. Но при UMaskустановке в 002UNIX сокет будет создан с владельцем opendkim:opendkimи привилегиями 664= rw-rw-r--.
Я понимаю, что членам группы (Postfix) необходимо читать и писать в сокет UNIX, но я не понимаю, почему почти все руководства в Интернете (А,Б,С...) оставить права на чтение другим?
Это общее заблуждение? Разве не разумное значение для UMaskбудет 007? Кроме того, файл PID создается с использованием тех же привилегий...
Если я проверю любой другой сокет UNIX в моей системе, некоторые из них также имеют права на другие... Почему это важно?
┌───┐
│ # │ root > mailer > ~
└─┬─┘
└─> ss -x -l | head -n 10
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
u_dgr UNCONN 0 0 /run/systemd/notify 14848 * 0
u_str LISTEN 0 128 /var/run/dovecot/director-userdb 13957121 * 0
u_str LISTEN 0 128 /run/systemd/private 14852 * 0
u_str LISTEN 0 100 /var/run/dovecot/dict 13957125 * 0
u_str LISTEN 0 128 /var/run/dovecot/dict-async 13957129 * 0
u_str LISTEN 0 1 /var/run/irqbalance568.sock 17673 * 0
u_dgr UNCONN 0 0 /run/systemd/journal/syslog 14859 * 0
u_str LISTEN 0 128 /var/run/dovecot/config 13957133 * 0
u_str LISTEN 0 128 /var/run/dovecot/login/login 13957135 * 0
┌───┐
│ # │ root > mailer > ~
└─┬─┘
└─> ls -l /var/run/dovecot/config
srw------- 1 root root 0 Dec 31 07:35 /var/run/dovecot/config
┌───┐
│ # │ root > mailer > ~
└─┬─┘
└─> ls -l /var/run/dovecot/login/login
srw-rw-rw- 1 root root 0 Dec 31 07:35 /var/run/dovecot/login/login
решение1
Использование umask, 002вероятно, зависит от общей umask по умолчанию 022, которая также соответствует образцу конфигурации opendkim.цитирует.
Так как opendkim использует одну настройку umask для pidfileифайл сокета, может возникнуть необходимость разрешить доступ на чтение pid-файла для других, так что файл сокета также будет создан с разрешением на чтение для других, какпобочный эффект.
Если вы даже не включаете создание pid-файлов (например, в systemd это вам не нужно) и добавляете пользователя postfix в группу opendkim, то 007имеет смысл использовать umask.
В качестве альтернативы вы можете позволить opendkim создать сокет в каталоге, который доступен только opendkim и postfix, например так:
$ cat /etc/tmpfiles.d/opendkim.conf
d /run/opendkim-postfix 0750 opendkim postfix -
Фрагмент основной конфигурации opendkim:
UMask 000
Socket local:/run/opendkim-postfix/opendkim.sock
Что приводит к:
# find /run/opendkim-postfix -printf '%M %m %p\n'
drwxr-x--- 750 /run/opendkim-postfix
srwxrwxrwx 777 /run/opendkim-postfix/opendkim.sock
Таким образом, вам не придется добавлять пользователя postfix в группу opendkim.
Качество руководств, на которые вы ссылаетесь, может быть ограничено, поскольку некоторые поставщики облачных услуг передают свою техническую документацию на аутсорсинг клиентам, которые затем поощряются облачными кредитами. Таким образом, как можно себе представить, такое руководство может использовать другие существующие руководства и примеры конфигураций без особой критики.