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

Reply via email to