Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1263727 > unrolled thread

Bug#1116595: Packaging issue: xfs_scrub_all_fail.service NoNewPrivileges breaks emailing reports

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1116595: Packaging issue: xfs_scrub_all_fail.service NoNewPrivileges breaks emailing reports Iustin Pop <iustin@debian.org> - 2025-09-29 00:00 +0200
    Bug#1116595: Packaging issue: xfs_scrub_all_fail.service NoNewPrivileges breaks emailing reports "Darrick J. Wong" <djwong@kernel.org> - 2025-10-13 20:00 +0200
      Bug#1116595: Packaging issue: xfs_scrub_all_fail.service NoNewPrivileges breaks emailing reports Iustin Pop <iustin@debian.org> - 2025-10-13 22:20 +0200
        Bug#1116595: Packaging issue: xfs_scrub_all_fail.service NoNewPrivileges breaks emailing reports "Darrick J. Wong" <djwong@kernel.org> - 2025-10-14 00:40 +0200
          Bug#1116595: Packaging issue: xfs_scrub_all_fail.service NoNewPrivileges breaks emailing reports "Darrick J. Wong" <djwong@kernel.org> - 2025-10-14 01:40 +0200
    Bug#1116595: [PATCH] xfs_scrub_fail: reduce security lockdowns to avoid postfix problems "Darrick J. Wong" <djwong@kernel.org> - 2025-10-14 01:40 +0200

#1263727 — Bug#1116595: Packaging issue: xfs_scrub_all_fail.service NoNewPrivileges breaks emailing reports

Package: xfsprogs
Version: 6.13.0-2+b1
Severity: important
X-Debbugs-Cc: iustin@debian.org

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
repeatedly, I get for a few days, every hour, hundreds of flagged log
entries by logcheck.

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.

Thanks!

-- System Information:
Debian Release: 13.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-security')
Architecture: amd64 (x86_64)

Kernel: Linux 6.12.43+deb13-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xfsprogs depends on:
ii  libblkid1           2.41-5
ii  libc6               2.41-12
ii  libdevmapper1.02.1  2:1.02.205-2
ii  libedit2            3.1-20250104-1
ii  libicu76            76.1-4
ii  libinih1            59-1
ii  liburcu8t64         0.15.2-2
ii  libuuid1            2.41-5
ii  python3             3.13.5-1
ii  python3-dbus        1.4.0-1

xfsprogs recommends no packages.

Versions of packages xfsprogs suggests:
ii  acl      2.3.2-2+b1
ii  attr     1:2.5.2-3
ii  quota    4.09-1+b1
ii  xfsdump  3.2.0-2

-- no debconf information

[toc] | [next] | [standalone]

#1265947

[yay, debian bugs aren't cc'ing linux-xfs consistently]

> 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?

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)

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

> Thanks!

--D

[toc] | [prev] | [next] | [standalone]

#1265993

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.

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

[toc] | [prev] | [next] | [standalone]

#1266009

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

[toc] | [prev] | [next] | [standalone]

#1266018

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

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

[toc] | [prev] | [next] | [standalone]

#1266017 — Bug#1116595: [PATCH] xfs_scrub_fail: reduce security lockdowns to avoid postfix problems

From: Darrick J. Wong <djwong@kernel.org>

Iustin Pop reports that the xfs_scrub_fail service fails to email
problem reports on Debian when postfix is installed.  This is apparently
due to several factors:

1. postfix's sendmail wrapper calling postdrop directly,
2. postdrop requiring the ability to write to the postdrop group,
3. lockdown preventing the xfs_scrub_fail@ service to have postdrop in
   the supplemental group list or the ability to run setgid programs

Item (3) could be solved by adding the whole service to the postdrop
group via SupplementalGroups=, but that will fail if postfix is not
installed and hence there is no postdrop group.

It could also be solved by forcing msmtp to be installed, bind mounting
msmtp into the service container, and injecting a config file that
instructs msmtp to connect to port 25, but that in turn isn't compatible
with systems not configured to allow an smtp server to listen on ::1.

So we'll go with the less restrictive approach that e2scrub_fail@ does,
which is to say that we just turn off all the sandboxing. :( :(

Reported-by: iustin@debian.org
Cc: <linux-xfs@vger.kernel.org> # v6.10.0
Fixes: 9042fcc08eed6a ("xfs_scrub_fail: tighten up the security on the background systemd service")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 scrub/xfs_scrub_fail@.service.in |   57 ++------------------------------------
 1 file changed, 3 insertions(+), 54 deletions(-)

diff --git a/scrub/xfs_scrub_fail@.service.in b/scrub/xfs_scrub_fail@.service.in
index 16077888df3391..1e205768133467 100644
--- a/scrub/xfs_scrub_fail@.service.in
+++ b/scrub/xfs_scrub_fail@.service.in
@@ -19,57 +19,6 @@ SupplementaryGroups=systemd-journal
 # can control resource usage.
 Slice=system-xfs_scrub.slice
 
-# No realtime scheduling
-RestrictRealtime=true
-
-# Make the entire filesystem readonly and /home inaccessible.
-ProtectSystem=full
-ProtectHome=yes
-PrivateTmp=true
-RestrictSUIDSGID=true
-
-# Emailing reports requires network access, but not the ability to change the
-# hostname.
-ProtectHostname=true
-
-# Don't let the program mess with the kernel configuration at all
-ProtectKernelLogs=true
-ProtectKernelModules=true
-ProtectKernelTunables=true
-ProtectControlGroups=true
-ProtectProc=invisible
-RestrictNamespaces=true
-
-# Can't hide /proc because journalctl needs it to find various pieces of log
-# information
-#ProcSubset=pid
-
-# Only allow the default personality Linux
-LockPersonality=true
-
-# No writable memory pages
-MemoryDenyWriteExecute=true
-
-# Don't let our mounts leak out to the host
-PrivateMounts=true
-
-# Restrict system calls to the native arch and only enough to get things going
-SystemCallArchitectures=native
-SystemCallFilter=@system-service
-SystemCallFilter=~@privileged
-SystemCallFilter=~@resources
-SystemCallFilter=~@mount
-
-# xfs_scrub needs these privileges to run, and no others
-CapabilityBoundingSet=
-NoNewPrivileges=true
-
-# Failure reporting shouldn't create world-readable files
-UMask=0077
-
-# Clean up any IPC objects when this unit stops
-RemoveIPC=true
-
-# No access to hardware device files
-PrivateDevices=true
-ProtectClock=true
+# No further restrictions because some installations may have MTAs such as
+# postfix, which require the ability to run setgid programs and other
+# foolishness.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web