Control: tags -1 + patch
On Sun, Jan 07, 2024 at 10:52:52PM +0100, Chris Hofstaedtler wrote:
> fuse, fuse3, and ntfs-3g use dpkg-statoverride on aliased paths in
> /bin: /bin/fusermount, /bin/fusermount3.
>
> They do so in their postinst scripts, only checking if a
> statoverride exists. If not, they run chmod on some programs.
> The postinst does not add a statoverride.
>
> As you know, these paths need to become canonicalized to /usr/{...}.
> When this happens, the old dpkg-statoverride entries stop working.
>
> Now my question: do you think it is worth migrating any such
> dpkg-statoverride automatically?
>
> If not, how should users/admins who previously created an override
> be informed about this problem? Some suggestions might be:
> - NEWS.Debian entry
> - trixie Release Notes
I have formerly split off bugs for fuse and fuse3 and this bug only
applies to ntfs-3g anymore.
I am less sure what to do about the case of ntfs-3g. Its own permission
depend on whether a statoverride for /bin/fusermount (owned by fuse)
exist. However, ntfs-3g depends on fuse3 and if one were to add a
statoverride for fuse3, it would apply to /bin/fusermount3 as
/bin/fusermount only is a link there. As such, the statoverride check
looks broken to me.
So one option is to discard it. At that point doing chmod in postinst no
longer makes sense. That chmod should happen at build time and apply to
data.tar.
The next option I see is extend it to also check for /bin/fusermount3,
which is how fuse3 is operated. If going this way, it would come down to
4 checks.
The third option is to ignore this and duplicate the check as is done
elsewhere regardless of whether the underlying check makes sense or not.
The next question is whether we should add NEWS for this. We already see
that it can't be a frequently used feature and that makes me think
rather not. Then if doing it via fusermount3, the user will already see
the NEWS of the fuse3 package, so I'd opt for no NEWS in either case.
I'm attaching a patch for the stupid third option (as that's the
minimal way of closing the matter), but I recommend thinking about what
it really is supposed to achieve and whether this code isn't actually
dead.
Helmut
diff --minimal -Nru ntfs-3g-2022.10.3/debian/changelog
ntfs-3g-2022.10.3/debian/changelog
--- ntfs-3g-2022.10.3/debian/changelog 2024-06-16 07:12:14.000000000 +0200
+++ ntfs-3g-2022.10.3/debian/changelog 2024-08-07 15:07:45.000000000 +0200
@@ -1,3 +1,11 @@
+ntfs-3g (1:2022.10.3-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Consider statoverrides in both aliased and canonical locations.
+ (DEP17 P3) (Closes: #1060229)
+
+ -- Helmut Grohne <[email protected]> Wed, 07 Aug 2024 15:07:45 +0200
+
ntfs-3g (1:2022.10.3-3) unstable; urgency=medium
* Fix use-after-free in 'ntfs_uppercase_mbs' (CVE-2023-52890)
diff --minimal -Nru ntfs-3g-2022.10.3/debian/ntfs-3g.postinst
ntfs-3g-2022.10.3/debian/ntfs-3g.postinst
--- ntfs-3g-2022.10.3/debian/ntfs-3g.postinst 2020-06-12 10:44:39.000000000
+0200
+++ ntfs-3g-2022.10.3/debian/ntfs-3g.postinst 2024-08-07 15:07:43.000000000
+0200
@@ -4,7 +4,8 @@
case "${1}" in
configure)
- if ! dpkg-statoverride --list /bin/fusermount > /dev/null 2>&1
+ if ! dpkg-statoverride --list /bin/fusermount > /dev/null 2>&1
&&
+ ! dpkg-statoverride --list /usr/bin/fusermount >
/dev/null 2>&1
then
chmod 4755 /bin/ntfs-3g
fi
