Aqui está o que eu faço: deixo o Exim entregar um e-mail usando um transporte de pipe para um dovecot-lda
processo. Este processo está sendo executado como usuário/grupo jdoe:jdoe
. (Eu verifiquei isso duas vezes usando um wrapper escrito por mim e truss
também.) A mensagem é entregue corretamente; ainda assim, vejo uma mensagem:
dovecot_lda transport output: lda(jdoe): Error: net_connect_unix(/var/run/dovecot/stats-writer) failed: Permission denied
Mas é certo que jdoe
tem as permissões necessárias pela wheel
associação ao grupo:
# ls -l /var/run/dovecot/stats-writer
srw-rw---- 1 dovecot wheel 0 7 Sep. 22:13 /var/run/dovecot/stats-writer
# id jdoe
uid=1001(jdoe) gid=1001(jdoe) groups=1001(jdoe),0(wheel),...
Então o que está acontecendo aqui?
Quando altero a propriedade do processo na configuração de transporte Exim, o aviso desaparece, mas a entrega falha. Quando altero o usuário do socket para jdoe
no serviço de estatísticas Dovecot, o problema ainda não é resolvido para outros usuários.
O que mais posso tentar?
A configuração de transporte exim é:
dovecot_lda:
driver = pipe
command = /usr/bin/truss -s 1024 -o /tmp/dovecot.truss -f /usr/local/libexec/dovecot/dovecot-lda -d "${lookup{$local_part}dsearch{/usr/local/misc/mail}}"
user = $local_part
group = $local_part
...
temp_errors = 64 : 69 : 70: 71 : 72 : 73 : 74 : 75 : 78
Provavelmente você precisará definir a
initgroups
opção no transporte para informar ao Exim que ele também precisa definir a lista de grupos suplementares.O kernel não os infere automaticamente do UID primário – cabe ao Exim definir o UID:GID primário e os GIDs suplementares.
(E não há uma única função "tornar-se usuário X" que o software possa usar, então eles precisam montar seu próprio código de troca de UID/GID a partir de várias APIs, com todas as inconsistências que isso acarreta; por exemplo, pular a chamada initgroups() "por causa do desempenho" ou algo assim.)