Permissions of basic executables lost after apt-get upgrade

Vinter · 12-08-2009, 04:40 AM

Hi,

during my routine system upgrade, I discovered loads of 'permission denied' errors when the postinst scripts were executed, mostly generated by access to runlevel and pidof. Upon further investigation, I luckily noticed that various basic executables had lost all permissions (and maybe ownerships, all of them belong to root:root). This is a complete list of find / -perm 000 output (minus the usual errors in /proc):

./var/run/crond.reboot
./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/runlevel
./sbin/swapon

It's obvious I won't be able to reboot my system, so I urgently need a list of suggested permissions and ownerships. Could someone maybe do a quick -l listing of the files in question on an up-to-date Debian Unstable or Sidux box? I would be most grateful.

Furthermore, how am I supposed to know if the packages I upgraded were installed correctly? Surprisingly, apt-get finished without an error (as did the various postinst subprocesses), so --fix-* will be of little help there. Should I maybe force reinstallation after correcting my dependencies? How can I make sure they won't be reset again? And what caused this error, anyways / how can I know if anything else got wrecked?

I suppose it's critical I don't mess up more stuff so I won't have to reboot, thus I'd rather wait for help than experiment with apt.

Thanks a bunch for any help.
David

Edit - Just to make this clear, the operation in question was a simple apt-get upgrade from official Debian / Sidux / *buntu sources only. (Except for wine.)

AlucardZero · 12-08-2009, 06:28 AM

Code:

---------- 1 root root 0 2009-12-06 12:12 ./var/run/crond.reboot
-rwxr-xr-x 1 root root 9208 2009-10-10 21:36 ./usr/sbin/tunelp
-rwxr-xr-x 1 root root 57872 2009-11-26 16:38 ./usr/sbin/ntpdate
ls: cannot access ./usr/sbin/tcpdump: No such file or directory
ls: cannot access ./usr/sbin/rotatelogs: No such file or directory
-rwxr-xr-x 1 root root 9976 2009-10-10 21:36 ./usr/sbin/rdev
-rwxr-xr-x 1 root root 10216 2009-12-02 06:07 ./usr/sbin/lpc
-rwxr-xr-x 1 root root 14256 2009-12-02 06:07 ./usr/bin/lpr
-rwxr-xr-x 1 root root 61440 2009-10-05 09:26 ./usr/bin/scp
-rwxr-xr-x 1 root root 14336 2009-12-02 06:07 ./usr/bin/lpq
-rwxr-xr-x 1 root root 10160 2009-12-02 06:07 ./usr/bin/lprm
-rwxr-xr-x 1 root root 25752 2009-10-26 12:49 ./usr/bin/eject
-rwxr-xr-x 1 root root 351136 2009-10-05 09:26 ./usr/bin/ssh
-rwsr-xr-x 1 root root 78584 2009-10-10 21:36 ./bin/mount
-rwsr-xr-x 1 root root 53136 2009-10-10 21:36 ./bin/umount
-rwxr-xr-x 1 root root 27928 2009-10-10 21:36 ./sbin/fsck
-rwxr-xr-x 1 root root 5376 2009-10-10 21:36 ./sbin/ctrlaltdel
-rwxr-xr-x 1 root root 88912 2009-10-10 21:36 ./sbin/fdisk
-rwxr-xr-x 1 root root 27408 2009-10-10 21:36 ./sbin/fsck.minix
-rwxr-xr-x 1 root root 15192 2009-10-25 18:38 ./sbin/halt
-rwxr-xr-x 1 root root 39920 2009-10-10 21:36 ./sbin/hwclock
-rwxr-xr-x 1 root root 37408 2009-10-25 18:38 ./sbin/init
-rwxr-xr-x 1 root root 15176 2009-10-25 18:38 ./sbin/killall5
-rwxr-xr-x 1 root root 6928 2009-10-10 21:36 ./sbin/mkfs
-rwxr-xr-x 1 root root 18544 2009-10-10 21:36 ./sbin/mkfs.minix
-rwxr-xr-x 1 root root 17088 2009-10-10 21:36 ./sbin/mkswap
-rwxr-xr-x 1 root root 4928 2009-10-25 18:38 ./sbin/runlevel
-rwxr-xr-x 1 root root 21520 2009-10-10 21:36 ./sbin/swapon

I run Testing. Looks like they're all 755 except u/mount which is 4755 and crond.reboot which is 000.

craigevil · 12-08-2009, 03:49 PM

Quote:

Edit - Just to make this clear, the operation in question was a simple apt-get upgrade from official Debian / Sidux / *buntu sources only.

You have Ubuntu sources in your sources.list? Why the hell would you do that?

My system is sid , I run apt-get dist-upgrade every couple of days; no problems here.

Vinter · 12-08-2009, 05:21 PM

Alucard: Thanks, no problems so far

Still didn't dare to thoroughly test stability, though.

craig: I don't quite remember why I introduced those, as far as I recall Ubuntu had some packets Debian / Sidux didn't. My packet list is selected by hand, so I figured it wouldn't hurt system stability, Sidux is more bleeding edge, anyways. (Alright, maybe I trusted dependency maintainers a little bit too much there... but apart from troubles with e17, which is more or less experimental anyways, this is the first problem I ran into after an apt-get upgrade.)

If you could explain why doing this is unnecessary / harmful, it would sure be interesting.

craigevil · 12-08-2009, 06:39 PM

Ubuntu packages are for Ubuntu, the depends can be different, the libs can be different. Installing Ubuntu packages on a debian system will sooner or later result in a messed up system.

what packages do you need that aren't in a Debian repo?

E17 has a Debian repo:
Enlightenment binary packages - http://packages.enlightenment.org/debian/
#deb http://packages.enlightenment.org/debian lenny main extras
#deb http://packages.enlightenment.org/debian squeeze main extras
#deb http://packages.enlightenment.org/debian sid main extras

With that many permissions messed up, your best bet would probably be to backup your important things and to reinstall.

evo2 · 12-08-2009, 06:46 PM

Quote:

Originally Posted by craigevil

#deb http://packages.enlightenment.org/debian sid main extras

If using sid, you can also get e17 directly from Debian.

Cheers,

Evo2.

Vinter · 12-08-2009, 07:01 PM

Quote:

E17 has a Debian repo

Alright, that is new. I've been installing it by SVN for a long time, anyways, as it seems to be the only way to make sure it's ecomorph-compatible.

I suppose I'll just try running my system with restored permissions and reinstall if necessary. The latter would be quite a hassle, though - last time I had to setup my DVB-T receiver and WLAN card it took me severals days, and then I'd still have to handcraft my package list, encrypt my disks, fight ecomorph's alpha state etc.

Thanks for helping

(And Ubuntu sources wil be removed. Their effect should wear off quite rapidly.)

evo2 · 12-08-2009, 07:19 PM

Quote:

Originally Posted by Vinter

And Ubuntu sources wil be removed. Their effect should wear off quite rapidly.

I'd explicitly remove all the ubuntu pacakges. IIRC, they will have the string "ubuntu" in the pacakge names, so you should be able to find them with:

Code:

dpkg -l '*ubuntu*' | grep ^ii

Then find the equivalent Debian package and version (if it exists) with

Code:

apt-cache show packagename

Then you can install the Debian version with

Code:

aptitude install pacakgename=version

Cheers,

Evo2.

alioop · 12-08-2009, 09:26 PM

Craigevil, I hope, made it clear enough. But if not, Whether they are Debian proper branches/versions or debian based distros stick to repos that pertain to your distro ONLY.

Mixing and matching might make fashionistas giddy with pleasure. But it doesn't work with Linux. It's a sure and certain path to hell and damnation! To say nothing about screwing up your OS. Oh, and your mother might disown you too.

craigevil · 12-09-2009, 05:14 AM

After removing the evil Ubuntu packages you can find out what packages you need to reinstall to get the permissions corrected by using apt-file search

Like apt-file search hwclock
util-linux: /etc/init.d/hwclock.sh
util-linux: /etc/init.d/hwclockfirst.sh
util-linux: /lib/udev/hwclock-set
util-linux: /lib/udev/rules.d/85-hwclock.rules
util-linux: /sbin/hwclock
util-linux: /usr/share/doc/util-linux/README.Debian.hwclock
util-linux: /usr/share/man/man8/hwclock.8.gz
So you now know hwlock is in the util-linux package, reinstalling it "should" rest the permissions correctly.

Quote:

But if not, Whether they are Debian proper branches/versions or debian based distros stick to repos that pertain to your distro ONLY.

Not quite true as long as the distro is a true debian based distro like sidux, antix, mepis, knoppix and a few others you can normally install packages from their repos safely. sidux for example is basically debian sid with a different kernel, artwork, and a few scripts; same for antix and knoppix.If they use the "official" debian repos in their sources.list you are Ok to use their repos 99% of the time. Just make sure the repo is the same branch of debian, stable, testing or unstable. Ubuntu on the other hand while being based on Debian changes the packages and does not use debian repos in its sources.list.

Vinter · 12-09-2009, 05:54 AM

Code:

root@frostbox:/home/vinter# dpkg -l '*ubuntu*' | grep ^ii
No packages found matching *ubuntu*.

Problem solved, I guess

Supposedly, the Ubuntu packages I once installed were replaced by more up-to-date Debian versions. The only repos using Ubuntu names in their paths were supplying me with wine, electricsheep and the likes, so maybe they weren't even Ubuntu-specific. (Removed them anyways, of course.)

Oh, and thanks for pointing me towards apt-file search, I was always wondering how you could do that.

alioop · 12-09-2009, 02:41 PM

Quote:

Originally Posted by craigevil

After removing the evil Ubuntu packages you can find out what packages you need to reinstall to get the permissions corrected by using apt-file search

Like apt-file search hwclock
util-linux: /etc/init.d/hwclock.sh
util-linux: /etc/init.d/hwclockfirst.sh
util-linux: /lib/udev/hwclock-set
util-linux: /lib/udev/rules.d/85-hwclock.rules
util-linux: /sbin/hwclock
util-linux: /usr/share/doc/util-linux/README.Debian.hwclock
util-linux: /usr/share/man/man8/hwclock.8.gz
So you now know hwlock is in the util-linux package, reinstalling it "should" rest the permissions correctly.

Not quite true as long as the distro is a true debian based distro like sidux, antix, mepis, knoppix and a few others you can normally install packages from their repos safely. sidux for example is basically debian sid with a different kernel, artwork, and a few scripts; same for antix and knoppix.If they use the "official" debian repos in their sources.list you are Ok to use their repos 99% of the time. Just make sure the repo is the same branch of debian, stable, testing or unstable. Ubuntu on the other hand while being based on Debian changes the packages and does not use debian repos in its sources.list.

craig, I'm not going to get too deep into this. But I have to disagree with you. It's a know fact that one should use repos or sources that are for their specific distros (Mepis, Ubuntu, Debian, etc). It keeps one from tearing out one's hair, gnashing their teeth, ripping their raiment as well as keeping their OS working.

I've never know of anybody mixing distro repos and getting good results. I guess there are way of doing this. But why bother when there are sources galore to use for your specific distro? I feel using sources that are related to your system will keep you from jumping through hoop to make it work. Good god! Why not?

Vinter · 06-08-2010, 06:09 PM

Still, I'm struggling with this, and I keep getting told this problem could not exist... luckily, I was able to track it down a bit - for instance:

Code:

root@frostbox:/# chmod 4755 /bin/mount
root@frostbox:/# ls -l /bin/mount
-rwsr-xr-x 1 root root 68316 May 14 15:05 /bin/mount

root@frostbox:/# apt-get clean
root@frostbox:/# apt-get --reinstall install mount

[snip]

Get:1 http://ftp.us.debian.org sid/main mount 2.17.2-2 [169kB]
Fetched 169kB in 2s (71.6kB/s)      
(Reading database ... 262604 files and directories currently installed.)
Preparing to replace mount 2.17.2-2 (using .../mount_2.17.2-2_i386.deb) ...
Unpacking replacement mount ...
Processing triggers for man-db ...
Setting up mount (2.17.2-2) ...

root@frostbox:/# ls -l /bin/mount
---------- 1 root root 68316 May 14 15:05 /bin/mount

What do you make of this? I'm completely stuck. (Same procedure would apply for all the above executables, I think; I tried like five of them.)

Thanks in advance,
David

Vinter · 06-08-2010, 06:57 PM

Sorry for replying to myself, but I found out a bit more when running dpkg with its debug flag set to 3773 (full detail).

Part of the output is here:

http://pastebin.com/1pSuzeny

This illustrates the only difference I could find beween an executable of the same packet (!) being installed with sane permissions and one with 0000 set. The line documenting a "stat override" seems to cause the problem - but why is it there?