[directly cc the xfs list now because dealing with the debian bug tracker is just too hard]
On Mon, Oct 13, 2025 at 10:09:14PM +0200, Iustin Pop wrote: > On 2025-10-13 10:41:06, Darrick J. Wong wrote: > > [yay, debian bugs aren't cc'ing linux-xfs consistently] > > They try to, but fail because the (new) bug source address is not > subscribed to linux-xfs, and thus there is a bounce. I haven't had time > to report this, sorry. > > > > I've struggled with this for a while because all my logs were spammed by > > > hundreds of lines of: > > > > > > postfix/postdrop[37291]: warning: mail_queue_enter: create file > > > maildrop/480926.37291: Permission denied > > > > > > And it took me a long while to dig this down to xfs_scrub reporting. > > > Problem setup: > > > > > > - mailer is postfix, which uses a setgid /usr/sbin/postdrop binary to > > > write to /var/lib/postfix/maildrop (mode 0730, group postdrop) > > > - the systemd unit for the xfs_scrub reporting, > > > /usr/lib/systemd/system/xfs_scrub_all_fail.service, contains: > > > > > > # xfs_scrub needs these privileges to run, and no others > > > CapabilityBoundingSet= > > > NoNewPrivileges=true > > > > > > Together, this means that the script > > > (/usr/libexec/xfsprogs/xfs_scrub_fail) composes the email, and pipes it > > > to "/usr/sbin/sendmail -t -i", which in turn invokes the postdrop > > > binary, but which can't get the sgid bit. But since it calls sendmail > > > > IOWs, postfix is installed and postdrop needs to be able to run as > > setgid, right? > > Correct. > > > Do you only need us to change the [email protected] file to have > > "NoNewPrivileges=false", or do you also need it to have > > "CapabilityBoundingSet=CAP_SETGID" ? > > > > The systemd documentation implies that you only need > > NoNewPrivileges=false to run setgid programs, but I don't know for sure. > > I'll try to test this and report back, but it sounds like you're in a > > better position to say for sure that postfix works. (I use msmtp) > > I don't know either, but sometimes in the next weeks I hope to get time > to test it. I suspect CapabilityBoundingSet=CAP_SETGID is an improvement > on NoNewPrivileges=False, but not required. No, both configuration directives fail to fix the problem. I even tried to selectively disable directives in the service configuration file, but for whatever reason it still fails even with seemingly unrelated things like RestrictRealtime=yes turned back on. The one thing that /does/ work consistently is to add SupplementalGroups=postdrop, but that makes the whole service fail if you don't happen to have postfix installed. Evidently postfix is *really* dependent upon postdrop being a setgid program and thereby being able to write to /var/spool/postfix/maildrop. There are some horrifying workarounds like this: https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/blob/main/systemd/system/0-EXAMPLES/30-allow-mail-postfix-via-msmtp.conf That advocate for installing msmtp, bindmounting msmtp over sendmail, and injecting a config file that just relays mail to the localhost MTA. I guess that works, but YUCK. I'll play around with this a little more, but maybe email reporting just isn't worth the trouble. --D > > > repeatedly, I get for a few days, every hour, hundreds of flagged log > > > entries by logcheck. > > > > Yikes. > > > > > Now, the Trixie kernel seems to not support scrubbing anyway, so I can > > > simply disable this, but it would be better to fix this and do an update > > > (in trixe), otherwise the log spamming is really annoying. > > > > Indeed. Forky (assuming it gets 6.18/6.24) should have online fsck > > turned on since upstream changed the kconfig default. Not that I have > > any idea how one gets kconfig options changed in Debian... > > Me neither, but I assume a new setting would just get the default. Once > sid kernels get to 6.18, I can test in a VM. > > thanks!
