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

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

[Darrick J. Wong]

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

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

[Darrick J. Wong]

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

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

[Darrick J. Wong]

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

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

[Darrick J. Wong]

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

[PATCH] xfs_scrub_fail: reduce security lockdowns to avoid postfix problems

[Darrick J. Wong]

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.

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

[Darrick J. Wong]

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.

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

[Andrey Albershteyn]

On 2025-10-13 16:34:24, Darrick J. Wong wrote:
> 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>

lgtm
Reviewed-by: Andrey Albershteyn <aalbersh@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.
> 

-- 
- Andrey

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

[Andrey Albershteyn]

On 2025-10-13 16:34:24, Darrick J. Wong wrote:
> 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>

lgtm
Reviewed-by: Andrey Albershteyn <aalbersh@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.
> 

-- 
- Andrey