/etc/msmtprc: Permission denied

[scruloose]

I'm open to the possibility that this is just a configuration error (maybe mine, maybe in the Debian package), but here's what I've got.

Debian testing (Trixie) system, kernel 6.7.12-amd64, systemd 256 (256.7-1)

I installed the msmtp-mta package:

$ msmtp --version

msmtp version 1.8.24
Platform: x86_64-pc-linux-gnu
TLS/SSL library: GnuTLS
Authentication library: GNU SASL; oauthbearer and xoauth2: built-in
Supported authentication methods:
plain scram-sha-1 scram-sha-256 external gssapi cram-md5 digest-md5 login ntlm oauthbearer xoauth2 
IDN support: disabled
NLS: enabled, LOCALEDIR is /usr/share/locale
Keyring support: Gnome 
System configuration file name: /etc/msmtprc
User configuration file name: /home/<user>/.msmtprc

Dropped in my /etc/msmtprc and /etc/aliases files (which are working on several other systems), and set permissions that I'm pretty confident should let msmtp read them both:

$ ls -lah /etc/msmtprc

-rw-r----- 1 root msmtp 2.1K Oct 16 11:48 /etc/msmtprc

$ ls -lah /etc/aliases

-rw-r--r-- 1 root root 26 Oct 16 13:31 /etc/aliases

I'm no AppArmor expert, but I believe this entry in /var/log/syslog indicates that it's ignoring msmtp entirely.

apparmor.systemd[687]: Skipping profile in /etc/apparmor.d/disable: usr.bin.msmtp

I've made no changes or overrides to the packaged default systemd service:

$ sudo systemctl cat msmtpd.service

# /usr/lib/systemd/system/msmtpd.service
[Unit]
Description=msmtp daemon
Documentation=man:msmtpd(1)

[Service]
DynamicUser=true
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
NoNewPrivileges=true
# NoNewPrivileges prevents the setgid mechanism from working
# so since msmtp is setgid in order to read /etc/msmtprc, the
# msmtp group need to be added in a different way
SupplementaryGroups=msmtp

Environment=INTERFACE=127.0.0.1 PORT=25
EnvironmentFile=-/etc/default/msmtpd

Type=simple
ExecStart=/usr/bin/msmtpd --interface=${INTERFACE} --port=${PORT}

Restart=always
RestartSec=60

ProtectHome=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Systemd shows the service up and running:

$ sudo systemctl status msmtpd.service

● msmtpd.service - msmtp daemon
     Loaded: loaded (/usr/lib/systemd/system/msmtpd.service; enabled; preset: enabled)
     Active: active (running) since Thu 2024-10-17 08:06:21 ADT; 4h 29min ago
 Invocation: 3d246cb4e8b34095b014270736580992
       Docs: man:msmtpd(1)
   Main PID: 796 (msmtpd)
      Tasks: 1 (limit: 9211)
     Memory: 180K (peak: 1.8M swap: 396K swap peak: 400K)
        CPU: 44ms
     CGroup: /system.slice/msmtpd.service
             └─796 /usr/bin/msmtpd --interface=127.0.0.1 --port=25

Oct 17 08:06:21 lincoln systemd[1]: Started msmtpd.service - msmtp daemon.

I can verify that the msmtpd process is running, and has the supplementary group as specified in the above unit file:

$ ps ax o user,supgrp,cmd | grep msmtp

msmtpd   msmtp,msmtpd        /usr/bin/msmtpd --interface=127.0.0.1 --port=25

So it really should be able to read that config file, but here's the output of trying to send a test message:

$ echo "This is the message text" | mail -v -s "test message from $HOSTNAME" root

ignoring system configuration file /etc/msmtprc: Permission denied
ignoring user configuration file /home/<user>/.msmtprc: No such file or directory
falling back to default account
sendmail: account default not found: no configuration file available
Can't send mail: sendmail process failed with error code 78

Invoking mail as root (via sudo) fails with the same error, which is as I would expect, given my understanding that it's still the systemd-managed msmtpd process that needs access to /etc/msmtprc, not mail itself.

Invoking msmtp directly from the command-line in "sendmail mode" as my regular user fails with the same error, as expected.

BUT if I invoke msmtp in sendmail mode as root, OR even as my regular user but with group set to msmtp, then it succeeds:

$ echo "This is the message text" | sudo -g msmtp msmtp -d root

loaded system configuration file /etc/msmtprc
ignoring user configuration file /home/<user>/.msmtprc: No such file or directory
falling back to default account
using account default from /etc/msmtprc
…

So… the AppArmor profile is disabled, the msmtpd service is running with supplementary group as expected, I've verified that command-line msmtp running unprivileged but with that group does work, (which also verifies that my /etc/msmtprc and /etc/aliases are correct and working), but somehow msmtpd is still getting permission denied trying to read /etc/msmtprc.

Any ideas where I might look next? Some new systemd access restriction mechanism, maybe?

[trallnag]

You could try overriding the systemd unit file with all the sandboxing removed