Hi Short story: /usr/bin/mlocate has changed permissions without reason. Sending this here in case anyone has got an idea or so that if others are seeing the same they could find this in google.
Long story: I've got a home server/desktop with an ITX board with Atom D510 that ran perfectly stable since I bought the board a couple months ago. A couple weeks ago I put a newly purchased SSD in it and reinstalled Squeeze from scratch. I've barely installed any software yet (and I deselected the desktop task, so it doesn't even have X on it), and have just used it as a file server for some other attached disks since. Today I've noticed that a system file has changed: chris@tn:~$ locate Foo locate: can not open `/var/lib/mlocate/mlocate.db': Permission denied chris@tn:~$ l /var/lib/mlocate/mlocate.db -rw-r----- 1 root mlocate 13864801 2011-09-06 06:25 /var/lib/mlocate/mlocate.db chris@tn:~$ l /usr/bin/mlocate -rwxr-sr-x 1 root 130 30492 2009-11-04 03:11 /usr/bin/mlocate where that binary should be owned by root.mlocate chris@tn:~$ grep mlocate /etc/group mlocate:x:104: chris@tn:~$ grep 130 /etc/group chris@tn:~$ tn:~# find -uid 130 / find: `/proc/1892/task/1892/fd/5': No such file or directory find: `/proc/1892/task/1892/fdinfo/5': No such file or directory find: `/proc/1892/fd/5': No such file or directory find: `/proc/1892/fdinfo/5': No such file or directory tn:~# find -gid 130 / /usr/bin/mlocate find: `/proc/2002/task/2002/fd/5': No such file or directory find: `/proc/2002/task/2002/fdinfo/5': No such file or directory find: `/proc/2002/fd/5': No such file or directory find: `/proc/2002/fdinfo/5': No such file or directory tn:~# meaning it's the only file everywhere with that gid or even uid (of course ignore the warnings, they are because of find finding its own proc entries), and the group doesn't exist. (Last change to the group file: -rw-r--r-- 1 root root 605 2011-08-25 00:17 /etc/group I think I've installed the system on 2011-08-18.) I've rebooted the machine but it didn't change, so I've just run chgrp (and chmod g+s) on the file. But I'm really wondering how this has happened. The /usr filesystem is unencrypted and on the SSD, so it could be some bit(s) flipped on the SSD, or in RAM and somehow written out (seems unlikely). 104 is b01101000 130 is b10000010 So that's *5* changed bits in the gid. Maybe the way SSDs work it could be the effect of a single bit change in the underlying flash? But I would have expected that I would get a read error instead in that case? (The SSD is a Kingston SSDNow V100 Series 64GB 2.5IN SSD SATA. In /proc/scsi/scsi it is shown as "Model: KINGSTON SV100S2 Rev: D110".) I haven't found any other binary with an odd group. I can't think of any way I would have caused it (I've also checked my bash history); in case there are others who have had the same issue, please speak up since then it's probably a bug somewhere. Christian. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAEjYwfUKRiWrfLqCB=Cjc7fM=OvgcRuUPq=e8hmnfsokvb0...@mail.gmail.com
