On Mon, Oct 13, 2025 at 03:31:56PM -0700, Darrick J. Wong wrote:
> [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.
Even the bindmounting craziness doesn't work, because that breaks
systems where msmtp is set up as the MTA, but not to listen on port 25
of ::1. At this point maybe I'll just revert to the approach that we
had prior to commit 9042fcc08eed ("xfs_scrub_fail: tighten up the
security on the background systemd service") and run with unrestricted
privileges as user mail. Then setgid works fine.
--D
> --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!
>
