This is a multi-part MIME message sent by reportbug.


Package: release.debian.org
Severity: normal
Tags: bullseye
X-Debbugs-Cc: nfs-utils@packages.debian.org, Sven-Haegar Koch <haegar@sdinet.de>, carnil@debian.org
Control: affects -1 + src:nfs-utils
User: release.debian.org@packages.debian.org
Usertags: pu

Dear stable release managers,

[ Reason ]
The kernel update for bullseye, from 5.10.218-1 to 5.10.221-1
(released as DSA DSA-5730-1), had in the 5.10.220 upstream release a
major backport of the NFS tstack. As it turns out that broke with the
old version of nfs-utils we have in bullseye the NFS re-exports.

[ Impact ]
Users which had such configurations under bullseye, to re-exprot over
NFS NFS mounted shares are not able to do so anymore with the update
to 5.10.221-1 (and possibly later, since not likely that there will be
a revert of the breaking change).

NFS re-export documentation had as well the note:

You'll need nfs-utils at least 1.3.5 (specifically, 3f520e8f6f5
"exportfs: Make sure pass all valid export flags to nfsd"). Otherwise,
on recent kernels, attempts to re-export NFS will likely result in
"exportfs: <path> does not support NFS export".

But until now 5.10.y had the old NFS stack where this did not cause
problems.

[ Tests ]
Sven-Haegar did explicitly test the nfs-utils package containing the
fix with such a configuration assessing that cherry-picking the
required upstream commit fixes the issue.

[ Risks ]
The commit is taken from the 1.3.5 nfs-utils series, where in bullseye
we have the 1.3.4 based one. The patch applies logically without
problems (with offsets). The commit makes sure that exportfs pass all
the flags to nfsd.

[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable

[ Changes ]
See above.

[ Other info ]
Technically one could argue this should go out via the
security-archive given the kernel did change in respect of the
breaking the old version of nfs-utils in bullseye. My argument is to
not have to force people not affected by this particular regression to
have updating the nfs-utils package, but rather batch the update in
the last bullseye point release (and depending if SRM see it fit, make
a SUA so affected users still could fetch the package earlier).

Let me know if you believe this should be handled differently.

Regards,
Salvatore

diff -Nru nfs-utils-1.3.4/debian/changelog nfs-utils-1.3.4/debian/changelog
--- nfs-utils-1.3.4/debian/changelog 2021-06-28 09:15:06.000000000 +0200
+++ nfs-utils-1.3.4/debian/changelog 2024-07-16 20:37:00.000000000 +0200
@@ -1,3 +1,9 @@
+nfs-utils (1:1.3.4-6+deb11u1) bullseye; urgency=medium
+
+ * exportfs: Make sure pass all valid export flags to nfsd (Closes: #1076448) +
+ -- Salvatore Bonaccorso <carnil@debian.org> Tue, 16 Jul 2024 20:37:00 +0200 +
nfs-utils (1:1.3.4-6) unstable; urgency=medium

* mountstats: Remove a shebang
diff -Nru nfs-utils-1.3.4/debian/patches/exportfs-Make-sure-pass-all-valid-export-flags-to-nf.patch nfs-utils-1.3.4/debian/patches/exportfs-Make-sure-pass-all-valid-export-flags-to-nf.patch
--- nfs-utils-1.3.4/debian/patches/exportfs-Make-sure-pass-all-valid-export-flags-to-nf.patch 1970-01-01 01:00:00.000000000 +0100
+++ nfs-utils-1.3.4/debian/patches/exportfs-Make-sure-pass-all-valid-export-flags-to-nf.patch 2024-07-16 20:37:00.000000000 +0200
@@ -0,0 +1,60 @@
+From: Kinglong Mee <kinglongmee@gmail.com>
+Date: Wed, 4 Jan 2017 09:20: