Bug#998242: cron-failure at .service delivery fails due to DynamicUser with exim

Vincent Bernat bernat at debian.org
Tue Dec 21 20:14:42 GMT 2021


 ❦  1 November 2021 14:27 +01, Yuri D'Elia:

> cron-failure@ is using DynamicUser=yes, however this causes a silent
> delivery failure when using exim4:
>
> systemd[1]: Starting cron-failure at cron-monthly.service...
> mail_on_failure[328561]: 2021-11-01 14:11:23 1mhX5v-001NTN-LU Failed
> to create spool file /var/spool/exim4//input//1mhX5v-001NTN-LU-D:
> Permission denied
> mail_on_failure[328561]: 2021-11-01 14:11:23 1mhX5v-001NTN-LU Failed
> to create spool file /var/spool/exim4//input//1mhX5v-001NTN-LU-D:
> Permission denied
> mail_on_failure[328561]: 2021-11-01 14:11:23 1mhX5v-001NTN-LU Failed
> to create spool file /var/spool/exim4//input//1mhX5v-001NTN-LU-D:
> Permission denied
> systemd[1]: cron-failure at cron-monthly.service: Deactivated successfully.
> systemd[1]: Finished cron-failure at cron-monthly.service.

I have the same issue with Postfix.

Dec 21 21:02:53 neo mail_on_failure[938987]: postdrop: warning: mail_queue_enter: create file maildrop/155101.938987: Permission denied
Dec 21 21:02:53 neo postfix/postdrop[938987]: warning: mail_queue_enter: create file maildrop/155101.938987: Permission denied
Dec 21 21:03:03 neo mail_on_failure[938987]: postdrop: warning: mail_queue_enter: create file maildrop/155516.938987: Permission denied
Dec 21 21:03:03 neo postfix/postdrop[938987]: warning: mail_queue_enter: create file maildrop/155516.938987: Permission denied

However, I don't know how it should work. Permissions for maildrop is:

 21:03 ❱ ls -ltrd /var/spool/postfix/maildrop
drwx-wx--T 2 postfix postdrop 4096 Dec 21 20:05 /var/spool/postfix/maildrop

With `T`, I am unable to create a file either:

 21:05 ❱ touch /var/spool/postfix/maildrop/titi
touch: cannot touch '/var/spool/postfix/maildrop/titi': Permission denied

I suppose only postdrop can write here:

 21:08 ❱ ls -ltrhA =postdrop
-r-xr-sr-x 1 root postdrop 19K Nov 13 22:05 /usr/sbin/postdrop

However, for some reason, the process is not part of the postdrop group:

 21:09 ❱ ls -ltrhAd /proc/938987
dr-xr-xr-x 9 cron-failure systemd-journal 0 Dec 13 07:19 /proc/938987

 21:11 ❱ systemctl cat cron-failure at cron-root-root-0.service
# /lib/systemd/system/cron-failure at .service
[Unit]
Description=systemd-cron OnFailure for %i
Documentation=man:systemd.cron(7)
RefuseManualStart=true
RefuseManualStop=true
ConditionFileIsExecutable=/usr/sbin/sendmail

[Service]
Type=oneshot
ExecStart=/lib/systemd-cron/mail_on_failure %i
DynamicUser=yes
Group=systemd-journal

 21:13 ❱ cat /proc/938987/status | grep Cap
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000

 21:13 ❱ capsh --decode=000001ffffffffff | grep setgid
0x000001ffffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore

So, process should be able to change group.

-- 
This night methinks is but the daylight sick.
		-- William Shakespeare, "The Merchant of Venice"



More information about the Pkg-systemd-maintainers mailing list