Suspecting permission bug in dpkg
Hi, I strongly suspect a bug in how dpkg handles permissions on
already existing directories.
**** Description
1. Let's look at the /usr/share/libtool/libltdl/ perms:
$ ls -ld /usr/share/libtool/libltdl/
drwxrwxrwx 2 root root 1024 Jul 7 21:59 /usr/share/libtool/libltdl
[nice, isn't it ?]
2. Check package and dpkg versions:
$ LC_ALL=C dpkg -l libtool dpkg
Desired=Unknown/Install/Remove/Purge
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-===============-==============-============================================
ii libtool 1.3.2-3 Generic library support script
ii dpkg 1.4.1.3 Package maintenance system for Debian Linux
3. Let's take the libtool_1.3.2-3_all.deb archive and check perms:
$ dpkg --fsys-tarfile /disc4/apt-archives/libtool_1.3.2-3_all.deb | tar tvf - | grep usr/share/libtool/libltdl/$
drwxr-xr-x root/root 0 1999-06-22 23:33 usr/share/libtool/libltdl/
[seems OK]
4. Let's try to re-install to get this fixed:
# LC_ALL=C dpkg -i /disc4/apt-archives/libtool_1.3.2-3_all.deb
(Reading database ... 77749 files and directories currently installed.)
Preparing to replace libtool 1.3.2-3 (using .../libtool_1.3.2-3_all.deb) ...
Unpacking replacement libtool ...
Setting up libtool (1.3.2-3) ...
Configuring libtool...
5. Check again:
$ ls -ld /usr/share/libtool/libltdl/
drwxrwxrwx 2 root root 1024 Jul 9 14:27 /usr/share/libtool/libltdl
[Lost :(]
6. This dir does not use suidregister:
$ grep libtool /etc/suid.conf
$
7. Doing the same with a file has a more expected behaviour.
**** Interpretation:
Files and dirs are not handled the same, as a given dir can be found
in many non-conflicting packaging. I suspect that the permissions on
the first package to install a dir are honored, but that subsequent
installs just ignore the dir if it is found here.
Thus, if the first package to install the dir was buggy wrt
permissions on that dir, then we'll stick with those buggy perms
forever. Even if the package is the only one ever referencing that
dir. Nice, eh ?
Possible solutions:
-> the easy one: always get perms on dirs from newest installed
package. Major drawback: any (trojan ?) 3rd-party package can open a
breach in the system.
-> the extremistic (not a short-term one): let's force ONE package
only to be responsible for a dir, just like it is for files.
Drawback: the packaging system will HAVE TO order the unpacking of
packages according to deps. I guess apt can do that, but dpkg alone
cannot, right ?
Any opinions on this ?
--
Yann Dirson | Why make M$-Bill richer & richer ?
<ydirson@multimania.com> | Support Debian GNU/Linux:
debian-email: <dirson@debian.org> | Cheaper, more Powerful, more Stable !
http://www.multimania.com/ydirson/ | Check <http://www.debian.org/>
Reply to: