FS#62371 - [nullmailer] mailq & nullmailer-queue needs to be setuid
Attached to Project:
Community Packages
Opened by Chris Drexler (CKolumbus) - Tuesday, 16 April 2019, 20:23 GMT
Last edited by Eli Schwartz (eschwartz) - Monday, 22 April 2019, 05:48 GMT
Opened by Chris Drexler (CKolumbus) - Tuesday, 16 April 2019, 20:23 GMT
Last edited by Eli Schwartz (eschwartz) - Monday, 22 April 2019, 05:48 GMT
|
Details
Description:
neither mailq nor nullmailer-queue can be used from normal user. Both programs should be setuid 'nullmailer', but aren't. Access to spool only works with correct permeissions > ls -l /var/spool/nullmailer total 12 drwx------ 2 nullmail nullmail 4096 Apr 16 21:51 failed drwx------ 2 nullmail nullmail 4096 Apr 16 21:51 queue drwx------ 2 nullmail nullmail 4096 Apr 16 21:51 tmp prw------- 1 nullmail nullmail 0 Apr 16 21:51 trigger Upstream nullmailer packages sets correct permissions within the .spec file, but this is not used for arch builds and no additional permissions are set in PKGBUILD file. Programs is not usable if my assessment is correct. Locally fixing the permissions to '04711' (as given in the nullmailer .spec file) fixes the issue Additional info: * package version : 2.2-1 * no upstream error found Steps to reproduce: * as root: pacman -S nullmailer for mailq: * as user: mailq -> Cannot change directory to queue. * as root: chmod 04711 /usr/bin/mailq * as user: mailq -> all OK for nullmailer-queue: * as user: echo Test | mailx "Test1" email@example.com -> nullmailer-inject: nullmailer-queue failed: 1 * as root: chmod 04711 /usr/bin/nullmailer-queue * as user: echo Test | mailx "Test1" email@example.com * as user: mailq -> entry in queue listed, no error from either mailq nor nullmailer-queue then queuing works |
This task depends upon
Closed by Eli Schwartz (eschwartz)
Monday, 22 April 2019, 05:48 GMT
Reason for closing: Duplicate
Additional comments about closing: Reproduced on Arch Linux in FS#62404
with better breakdown of the cause.
Monday, 22 April 2019, 05:48 GMT
Reason for closing: Duplicate
Additional comments about closing: Reproduced on Arch Linux in
This is not an exploitable security issue and it doesn't crash the system or cause boot failure.
Regarding the snippet: found it now, I wasn't aware of this before (understanding systemd is not my strength). Nevertheless it doesn't work, I'm investigating.
Manually executing `systemd-tmpfiles --remove --create` fixes the issue, so I guess I have to look why this doesn't get executed automatically.
Only the 'z' actions on the two binaries are missing. But when mimicking the pacman hook execution from the command line, all is set fine afterwards (echo /usr/lib/tmpfiles.d/nullmailer.conf | /usr/share/libalpm/scripts/systemd-hook tmpfiles).
Any ideas what this could be, or how to debug this further?
nullmailer.pacman.txt (24.8 KiB)
Your systemd package was built by Manjaro and does not correspond to any version of systemd which Arch Linux has ever packaged.