Package: fetchmail
Version: 6.4.16-1
Severity: grave
This is currently run on testing since ages. I had to restart due to a changed
fingerprint and the global service started to fail with:
$ systemctl status fetchmail.service
● fetchmail.service - LSB: init-Script for system wide fetchmail daemon
Loaded: loaded (/etc/init.d/fetchmail; generated)
Active: active (exited) since Wed 2021-06-16 08:07:28 CEST; 1h 23min ago
Docs: man:systemd-sysv-generator(8)
Tasks: 0 (limit: 9313)
Memory: 0B
CPU: 0
CGroup: /system.slice/fetchmail.service
giu 16 08:07:28 klecker systemd[1]: Starting LSB: init-Script for system wide
fetchmail daemon...
giu 16 08:07:28 klecker fetchmail[846490]: Starting mail retriever agent:
fetchmail.
giu 16 08:07:28 klecker systemd[1]: Started LSB: init-Script for system wide
fetchmail daemon.
giu 16 08:07:28 klecker fetchmail[846499]: starting fetchmail 6.4.16 daemon
giu 16 08:07:28 klecker fetchmail[846499]: fetchmail: lock creation failed,
pidfile "/run/fetchmail/fetchmail.pid": File o directory non esistente
The /run/fetchmail directory ownership is correct (fetchmail:nogroup) and if I
start the process by hand with:
sudo -u fetchmail -- fetchmail --pidfile /run/fetchmail/fetchmail.pid
--nosslcertck -f /etc/fetchmailrc --syslog
it works regularly. So the problem is with the init script, still used by
systemd. Here:
start-stop-daemon -S -o -q -p $PIDFILE -x $DAEMON -u $USER -c $USER --
$OPTIONS;
I think the problem resides. I see that the pidfile is passed at the same time
to start-stop-daemon and the daemon (-p and $OPTIONS) which
run in unprivileged mode.
I changed the instruction into:
start-stop-daemon -S -o -q -x $DAEMON -u $USER -c $USER -- $OPTIONS;
and now it works. Note that currently man page reports:
Warning: Using this match option with a world-writable pidfile or
using it alone with a daemon that writes the pidfile as an unprivileged
(non-root) user will be refused with an
error (since version 1.19.3) as this is a security risk, because
either any user can write to it, or if the daemon gets compromised, the
contents of the pidfile cannot be trusted,
and then a privileged runner (such as an init script executed as
root) would end up acting on any system process. Using /dev/null is exempt
from these checks.
and bullseye runs dpkg v1.20.9 currently.
I'm tagging this bug as grave because even if fetchmail is not always used in
daemon mode, it breaks for sure existing configurations in an unexpected way
(and the reason
is quite obscure for the casual user)
- cheers
-- System Information:
Debian Release: 11.0
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages fetchmail depends on:
ii adduser 3.118
ii debianutils 4.11.2
ii libc6 2.31-12
ii libcom-err2 1.46.2-1
ii libgssapi-krb5-2 1.18.3-5
ii libkrb5-3 1.18.3-5
ii libssl1.1 1.1.1k-1
ii lsb-base 11.1.0
Versions of packages fetchmail recommends:
ii ca-certificates 20210119
Versions of packages fetchmail suggests:
ii exim4-daemon-heavy [mail-transport-agent] 4.94.2-5
pn fetchmailconf <none>
pn resolvconf <none>
-- Configuration Files:
/etc/default/fetchmail changed:
OPTIONS=--nosslcertck
START_DAEMON=yes
PIDFILE=/run/fetchmail/fetchmail.pid
-- no debconf information
--
Francesco P. Lovergine
