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. > > 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!
