Re: Packaging issue: xfs_scrub_all_fail.service NoNewPrivileges breaks emailing reports

["Darrick J. Wong" <djwong@kernel.org>]

[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 xfs_scrub_fail@.service 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!