[SOLVED] Permissions set to 000 when installing package

Vinter · 11-06-2011, 06:50 AM

Hi!

I just did an apt-get dist-upgrade, and ran into an old problem: Some crucial executables had their permissions set to 000, sometimes breaking the upgrade process. The list is as follows:

/usr/sbin/tunelp, /usr/sbin/ntpdate, /usr/sbin/tcpdump, usr/sbin/rotatelogs, /usr/sbin/rdev, /usr/sbin/lpc, /usr/bin/lpr, /usr/bin/scp, /usr/bin/lpq, /usr/bin/lprm, /usr/bin/eject, /usr/bin/ssh, /bin/mount, /bin/umount, /sbin/fsck, /sbin/ctrlaltdel, /sbin/fdisk, /sbin/fsck.minix, /sbin/halt, /sbin/hwclock, /sbin/init, /sbin/killall5, /sbin/mkfs, /sbin/mkfs.minix, /sbin/mkswap, /sbin/modprobe, /sbin/runlevel, /sbin/swapon

I had to set them back to their original permissions manually, and as this leaves quite an uneasy feeling, I'd like to avoid this in the future.

Thus, as an example, I tried to reinstall mount:

Code:

root@frostbox:/home/vinter# chmod 4755 /bin/mount
root@frostbox:/home/vinter# ls -l /bin/mount
-rwsr-xr-x 1 root root 84944 Aug  3 16:02 /bin/mount
root@frostbox:/home/vinter# apt-get clean
root@frostbox:/home/vinter# apt-get --reinstall install mount
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 19 not upgraded.
Need to get 206 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://ftp.de.debian.org/debian/ sid/main mount i386 2.19.1-5 [206 kB]
Fetched 206 kB in 0s (208 kB/s)
(Reading database ... 267672 files and directories currently installed.)
Preparing to replace mount 2.19.1-5 (using .../mount_2.19.1-5_i386.deb) ...
Unpacking replacement mount ...
Processing triggers for man-db ...
Setting up mount (2.19.1-5) ...
localepurge: Disk space freed in /usr/share/locale: 0 KiB
localepurge: Disk space freed in /usr/share/man: 0 KiB
localepurge: Disk space freed in /usr/share/gnome/help: 0 KiB
localepurge: Disk space freed in /usr/share/omf: 0 KiB
localepurge: Disk space freed in /usr/share/doc/kde/HTML: 0 KiB

Total disk space freed by localepurge: 0 KiB

root@frostbox:/home/vinter# ls -l /bin/mount
---------- 1 root root 84944 Aug  3 16:02 /bin/mount

Seems to be reproducable, but it has nothing to do with the package: #debian on FreeNode tells me noone has experienced similar problems with it.

The package source should be OK:

Code:

root@frostbox:/home/vinter# apt-cache policy mount
mount:
  Installed: 2.19.1-5
  Candidate: 2.19.1-5
  Version table:
 *** 2.19.1-5 0
        500 http://ftp.de.debian.org/debian/ sid/main i386 Packages
        100 /var/lib/dpkg/status

ftp.us.debian.org exhibits the same problems.

Trying to get further detail:

Code:

root@frostbox:/var/cache/apt/archives# dpkg -D10 -i mount_2.19.1-5_i386.deb

I get the following:

http://pastebin.com/70DyEQY4

of which this excerpt should be interesting:

Code:

D000010: tarobject ti->name='.' mode=40755 owner=0.0 type=53(d) ti->linkname='' namenode='/.' flags=2 instead='<none>'
D000010: tarobject ti->name='./bin' mode=40755 owner=0.0 type=53(d) ti->linkname='' namenode='/bin' flags=2 instead='<none>'
D000010: tarobject ti->name='./bin/umount' mode=104755 owner=0.0 type=48(-) ti->linkname='' namenode='/bin/umount' flags=2 instead='<none>'
D000010: ensure_pathname_nonexisting `/bin/umount.dpkg-new'
D000010: ensure_pathname_nonexisting `/bin/umount.dpkg-tmp'
D000010: tarobject ... stat override, uid=0, gid=0, mode=0000
D000010: tarobject ti->name='./bin/mount' mode=104755 owner=0.0 type=48(-) ti->linkname='' namenode='/bin/mount' flags=2 instead='<none>'
D000010: ensure_pathname_nonexisting `/bin/mount.dpkg-new'
D000010: ensure_pathname_nonexisting `/bin/mount.dpkg-tmp'
D000010: tarobject ... stat override, uid=0, gid=0, mode=0000
D000010: tarobject ti->name='./bin/findmnt' mode=100755 owner=0.0 type=48(-) ti->linkname='' namenode='/bin/findmnt' flags=2 instead='<none>'
D000010: ensure_pathname_nonexisting `/bin/findmnt.dpkg-new'
D000010: ensure_pathname_nonexisting `/bin/findmnt.dpkg-tmp'

As can be concluded from the log, umount and mount lose their permissions, while findmnt retains them. So, for some reason, tar is overriding the permissions just for the former. Logical step would be to reproduce this error manually:

Code:

root@frostbox:/var/cache/apt/archives# ar x mount_2.19.1-5_i386.deb 
root@frostbox:/var/cache/apt/archives# tar xpf data.tar.gz 
root@frostbox:/var/cache/apt/archives# ls -l bin/mount 
-rwsr-xr-x 1 root root 84944 Aug  3 16:02 bin/mount

... what?

So, manual extraction yields a perfectly fine executable, but dpkg somehow seems to screw up.

Why?

Thank you for any help

Vinter

PS: Yes, I know I had a thread about this a year ago, but it went into the wrong direction when a Ubuntu repository was discovered in my sources.list. It was just for WINE and had nothing to do with the error in question. Maybe someone can help me now.

jthill · 11-06-2011, 07:56 AM

You don't mention googling 'stat override'. The results sure look good for this.

Vinter · 11-06-2011, 08:42 AM

I did google the line and parts of it, finding only my own questions about the issue at hand, and only your comment urged me to find the right combination of words. It actually seems that the mode is overridden in /var/lib/dpkg/statoverride (did not know about dpkg-statoverride, else I would have checked earlier), and this seems to be a desired mechanism. Removing the overrides allows me to install the package in a clean way, so thank you very much for pointing this out

I would never have found it myself.

But well now - how come the overrides are there? What could be a reason for adding them? And how can I make sure they do not reappear? The list of overrides seems to have changed since I last asked about the problem (at least modprobe was not affected last time), so there seems to be something touching that config file. Does the packaging system have a log that tells me which tool accessed it?

(What comes to mind is that I ran Bastille a long time ago, before the problem first appeared, and that this could be some sort of hardening mechanism. As far as I know, though, Bastille only acts when I ask it to, and does not change things without interaction. Still, as I may be mistaken about the list changing: Can a common option to the tool produce such behavior?)

PS: The overrides are as follows: http://pastebin.com/FxFjxsRk

What is their purpose? How can I know what lines to remove safely?

widget · 11-06-2011, 11:24 AM

I would not ever remove any of the lines. Just comment them out. That way if it turns out to be a mistake you can easily uncomment it again.

jthill · 11-06-2011, 07:05 PM

I'd never heard of dpkg-statoverride either. I just keyed off the 'mode=0000' you'd mentioned and googled the nearest phrase that looked jargon-y. Really.

Vinter · 11-12-2011, 09:01 AM

If anyone else stumbles over this: Bastille was indeed responsible, which was due to a bug in its Debian integration. Looking at the above config file, anything starting with "root root 0" may go, judging from comparison with other machines. If the bug occurs again, it may be prevented by answering "no" to the question about setting more restrictive permissions to administrative programs (which would, normally, only remove setuid root bits and such).