Found the cause of this issue. Tracking fix as DOV-8966.
Op 4-3-2026 om 13:14 schreef Roland Hieber via dovecot:
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 `procmail`
wrapper 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
_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
