FS#62404 - [nullmailer][systemd] missing setuid bit for nullmailer-queue
Attached to Project:
Community Packages
Opened by Sebastian Schloßer (Sebastian256) - Friday, 19 April 2019, 18:05 GMT
Last edited by Eli Schwartz (eschwartz) - Friday, 19 April 2019, 20:41 GMT
Opened by Sebastian Schloßer (Sebastian256) - Friday, 19 April 2019, 18:05 GMT
Last edited by Eli Schwartz (eschwartz) - Friday, 19 April 2019, 20:41 GMT
|
Details
I cannot send mail using nullmailer 2.2-1.
Using an unprivileged user, the sendmail command fails with "nullmailer-inject: nullmailer-queue failed: 1" Using root, the mail gets queued but not delivered: "nullmailer-send: Can't open file '1555695487.2489'" The reason for the problem is that mails are put into the /var/spool/nullmailer/queue folder by nullmailer-queue. That works only if the executing user is nullmail or root. The mails are then read from there by nullmailer-send. Since that process is executed by the nullmail user, it cannot read queued files owned by root with mode 600. The solution is to set the setuid bit for the nullmailer-queue executable. Then mails can be queued and always have the correct owner. |
This task depends upon
Closed by Eli Schwartz (eschwartz)
Friday, 19 April 2019, 20:41 GMT
Reason for closing: Fixed
Additional comments about closing: Worked around in nullmailer 2.2-2
Friday, 19 April 2019, 20:41 GMT
Reason for closing: Fixed
Additional comments about closing: Worked around in nullmailer 2.2-2
Is there a way to apply the permissions immediately on package install, or at least wo warn the user that he has to reboot?
I have put a 'strace' call before '/usr/bin/systemd-tmpfiles --create' in /usr/share/libalpm/scripts/systemd-hook.
Look at this excerpt:
openat(4, "nullmailer-queue", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 5
fstat(5, {st_mode=S_IFREG|0755, st_size=26488, ...}) = 0
close(4) = 0
fstat(5, {st_mode=S_IFREG|0755, st_size=26488, ...}) = 0
chmod("/proc/self/fd/5", 04755) = 0
fchownat(5, "", 962, -1, AT_EMPTY_PATH) = 0
close(5) = 0
For me it looks like the chmod to 04755 is done before the chown to 962 (nullmail), but chown implicitly resets the setuid bit.
The second (manual) invocation of systemd-tmpfiles does no chown anymore, because the owner is already correct.
I'll experiment a bit with systemd-tmpfiles to find the smallest possible example and then file a bug against systemd.
Thanks again for the hint with the hook that helped me to find it.
FS#62371except on actual Arch Linux. I could swear this used to work, though. The package has been that way for over a year, BTW. Did something change in systemd?...
So it does correctly set the ownership, but not the relevant permission.
Chmod is in line 820, chown at line 833. The order has been like this for a year.
To hit this bug you need to install/update nullmailer and then send mails before you reboot the system or install another package that also triggers the tmpfiles hook.
The first invocation of systemd-tmpfiles sets the permissions (including setuid bit) and than changes the owner to nullmail, which clears the setuid bit again. A second invocation (reboot/manual/other package triggers hook) sets the setuid bit and since the owner is already correct, no chown is done and the bit stays until you update/reinstall nullmailer.