O procedimento de instalação do Postfix criou um usuário do sistema postfixe seu grupo primário, postfixenquanto o procedimento de instalação do OpenDKIM criou um usuário do sistema opendkime seu grupo primário opendkim.
Para permitir que Postfix e OpenDKIM trabalhem juntos, a maioria dos administradores faz duas coisas:
A
Eles anexam um grupo secundário opendkimao Postfix.
B
Eles definiram o arquivo de configuração OpenDKIM /etc/opendkim.confpara criar um soquete UNIX usando estas três (duas) linhas:
UMask 002
PidFile /var/run/opendkim/opendkim.pid
Socket local:/var/spool/postfix/opendkim/opendkim.sock
A documentação oficial do OpenDKIM afirma isto para o parâmetro de configuração UMask:
Solicita uma máscara de permissões específica para ser usada na criação de arquivos. Isso realmente se aplica apenas à criação do soquete quando Socket especifica um soquete de domínio UNIX e ao PidFile (se houver);
Eu sei que os soquetes UNIX são convenientes porque podem limitar os privilégios do usuário. No meu caso, quero que o OpenDKIM funcione com o Postfix da forma mais segura possível. Mas com o soquete UNIX UMaskdefinido 002será criado com propriedade opendkim:opendkime privilégios 664= rw-rw-r--.
Entendo que os membros do grupo (Postfix) precisam ler e escrever no soquete UNIX, mas não entendo por que quase todos os tutoriais online (A,B,C...) deixar permissões de leitura para outras pessoas?
Este é um equívoco geral? Não seria um valor razoável para UMaskbe 007? Além disso, o arquivo PID é criado usando os mesmos privilégios...
Se eu verificar qualquer outro soquete UNIX no meu sistema, alguns também terão direitos para outros... Por que isso é importante?
┌───┐
│ # │ 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
Responder1
O uso de uma umask de 002provável é influenciado pelo umask padrão comum de 022- que também é a configuração de amostra do opendkimcita.
Como o opendkim usa uma configuração umask para o pidfileeo arquivo de soquete, pode haver a necessidade de permitir acesso de leitura no pidfile para outros, de modo que também o arquivo de soquete seja criado com permissão de leitura para outros, como umefeito colateral.
Se você nem mesmo habilita a criação de pidfile (por exemplo, com systemd você não precisa disso) e adiciona o usuário postfix ao grupo opendkim, então uma máscara de 007faz sentido.
Alternativamente, você pode criar o soquete opendkim em um diretório que só é acessível por opendkim e postfix como este:
$ cat /etc/tmpfiles.d/opendkim.conf
d /run/opendkim-postfix 0750 opendkim postfix -
Snippet de configuração principal do opendkim:
UMask 000
Socket local:/run/opendkim-postfix/opendkim.sock
O que resulta em:
# find /run/opendkim-postfix -printf '%M %m %p\n'
drwxr-x--- 750 /run/opendkim-postfix
srwxrwxrwx 777 /run/opendkim-postfix/opendkim.sock
Dessa forma você não precisa adicionar o usuário postfix ao grupo opendkim.
A qualidade dos tutoriais que você cita pode ser limitada, porque alguns provedores de nuvem terceirizam sua documentação técnica para clientes que são incentivados por créditos de nuvem. Assim, como se pode imaginar, tal tutorial pode usar outros tutoriais existentes e exemplos de configurações sem muita crítica.