Package: fuse-utils
Version: 2.5.3-4.1
Severity: important
Tags: patch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I upgraded fuse-utils today and noticed that although a command run by
the postinst script failed (the invocation of dpkg-statoverride) the
script did not abort.
dpkg-statoverride failed to run because an override for
/usr/bin/fusermount already existed. The net result is that the
mode of that file would never have been updated if I hadn't noticed the
failure myself.
In my opinion, ignoring the failure of commands by appending '|| true'
to them is careless and can even be dangerous. I respectfully suggest a
number of changes:
First, the postinst script.
This change will cause package installation to fail if there is a genuine
error while creating the fuse group (as it should; without the group the
package will not function and so the administrator needs to be notified
of the failure so it can be rectified). But since addgroup is only run
if the fuse group is not already present, it will not fail if the group
already exists (which, looking at #383076, seems to be the reason for
ignoring the failure of addgroup).
-addgroup --system fuse || true
+getent group fuse >/dev/null || addgroup --system fuse
I don't think the maintainer script should blindly change the permission
of the /dev/fuse file (or any other file). If the administrator has
customised the owner or permission of the device then his changes should
be preserved:
-if [ -c /dev/fuse ]; then chown root:fuse /dev/fuse; fi
-if [ -c /dev/.static/dev/fuse ];
- then chown root:fuse /dev/.static/dev/fuse;
-fi
The owner (and permissions) for the device should only be set by
udev, or MAKEDEV.
About the call to udevcontrol... the man page for the utility does not
mention what the reload_rules command does, or why it may fail... so I'm
not sure how to replace the use of || true in this case.
Finally, I think the use of dpkg-statoverride to set the permission of
/usr/bin/fusermount is wrong. dpkg-statoverride is a tool for the system
administrator to use to *override* the default permissions of a file; package
maintainer scripts should simply use chown and chmod, after having
checked whether the administrator has overriden a file's permissions.
-dpkg-statoverride --add --update root fuse 4750 /usr/bin/fusermount || true
+if ! dpkg-statoverride --list /usr/bin/fusermount >/dev/null; then
+ chown root:fuse /usr/bin/fusermount
+ chmod 4750 /usr/bin/fusermount
+fi
Now, the postrm script.
IMO the administrator's decision to override the permissions of the file
should be removed (if at all) only when the package is purged:
-dpkg-statoverride --remove /usr/bin/fusermount || true
And again, if the removal of the fuse group fails, the administrator
should be informed so that he can remove the group manually. Not the use
of if...fi instead of &&; this is done so that the command will not cause the
script to fail if the fuse group is not present
-delgroup --system fuse || true
+if getent group fuse >/dev/null; then delgroup --system fuse; fi
The final issue is how to handle upgrades from earlier versions of the
package that used dpkg-statoverride to set the permission of
/usr/bin/fusermount. I suggest creating a preinst script (note the
version number being compared against is 2.5.3-5; this must be the
version number of the package that fixes this bug):
#!/bin/sh -e
if test "$2" -lt '2.5.3-5' then
stat="$(dpkg-statoverride --list /usr/bin/fusermount)"
if test "$stat" = 'root fuse 4754 /usr/bin/fusermount; then
dpkg-statoverride --remove /usr/bin/fusermount
elif test "$stat" = 'root fuse 4750 /usr/bin/fusermount; then
dpkg-statoverride --remove /usr/bin/fusermount
fi
fi
This will result in a clean system in all three cases:
1. where the user has not created their own statoverride for the file,
the existing statoverride will be removed
2. where the user has not created their own statoverride for the file, and
upgraded from an older version of fuse-utils where fusermount was
shipped mode 4754, the existing statoverride will be removed and the
postinst will update fusermount to be mode 4750
3. where the user has created their own statoverride for the file, it
will be preserved, and the postinst will not change the mode of the
file
The messages that made me realise that using dpkg-statoverride in a
package's maintainer scripts are archived at
<http://lists.debian.org/debian-mentors/2001/02/msg00170.html>
and <http://lists.debian.org/debian-mentors/2001/02/msg00174.html>.
- -- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (530, 'testing'), (520, 'unstable'), (510, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-k7
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Versions of packages fuse-utils depends on:
ii adduser 3.97 Add and remove users and groups
ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries
ii makedev 2.3.1-83 creates device files in /dev
ii sed 4.1.5-1 The GNU sed stream editor
ii ucf 2.0014 Update Configuration File: preserv
ii udev 0.100-1 /dev/ and hotplug management daemo
fuse-utils recommends no packages.
- -- debconf information:
fuse-utils/groupcreate: false
fuse-utils/groupdelete: true
fuse-utils/group: fuse
fuse-utils/grouprenamemigrate: true
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFEzU+shl/216gEHgRAgTzAKDFuQvee3fV/lo9trDxuHKRrgbhEgCgstco
/155BafmAztH00HkUpPhHTc=
=Od3D
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
