On 04/03/2026 14:14 EET Roland Hieber via dovecot <dovecot@dovecot.org> wrote:
Hi,
Ultimately I'm trying to call procmail via a
pipe "procmail";in my Sieve script on Dovecot 2.4.1. I have therefore created the respective wrapper script in /usr/lib/dovecot/sieve-pipe/procmail, but I noted that the script is apparently run as root. With some debug output in the wrapper script, I see:# `id` output uid=0(root) gid=1059(rhi) groups=1059(rhi),116(dovecot) # `pstree -s -u $$` systemd(1)---dovecot(1064)---lmtp(266577,rhi)---procmail(266706,root)---pstree(266711)This Dovecot gets mail delivered via LMTP from another server. 1059 (rhi) is my local user ID on the IMAP server both in /etc/passwd and in /etc/dovecot/users (using auth-passwdfile.conf.ext in 10-auth.conf instead of auth-system.conf.ext), since mail needs to be delivered and chown'ed correctly into Maildirs that should be user-accessible. However I don't understand how the
procmailwrapper can be run as the root user rights when the LMTP process starting it is running as my own user?!?I'd like to prevent procmail from running as root as far as possible, so for now I've been able to work around this by wrapping the procmail call into an additional
sudo -U $USER(after determining the user who owns the target maildir), but I'd like to understand the problem a bit further and like to know if this is really how calling sieve-extprograms is supposed to work – I'd have expected that the external scripts are also run as my unprivileged user.I'm running a fairly standard config on Debian stable (dovecot package version 1:2.4.1+dfsg1-6+deb13u2) with only minimal changes by enabling the passwdfile backend and some sieve plugins.
Thanks for any insights,
- Roland
--
Can you share your doveconf output? Also is procmail setuid binary?
Aki