Oops! I did a chown -R root from the '/' level

Wujen · 04-06-2005, 02:54 PM

And consequently almost everything on the machine got owned by root, save for a few /dev's that wouldn't let me. I've got a decent amount of it back in working order but now only root can use the su command with any effectiveness. Any other account that tries to use su hesitates before receiving an error that the password is incorrect. The password is correct so I'm led to believe I've made some vital file in the authentication process inaccessible to anyone but root. I'm guessing it's one that should be owned by a system user rather than root, or maybe I need to re-SETUID root on one or all of the files involved. The problem is, I don't know all of the files involved... /usr/bin/su, /etc/passwd, /etc/shadow. Can anyone help? This is on a FC3 distribution with everything installed (if not all used).

Also, since this little accident my System Log has been getting spammed with...

pam_timestamp_check: pam_timestamp: `/' owner GID != 0

Any clues for this one?

Mara · 04-06-2005, 03:20 PM

The message is rather easy. GID is group id (owner group). Id 0 is root. So it complains that / is not owned by group root. Check it.

Wujen · 04-06-2005, 04:16 PM

Thanks Mara, that cleared the spam up. The GID was set to 'adm'. I left it alone after Googling the phrase and finding one guy's comment that it was supposed to be that way. So much for that.

Oh, I found another quirk. The locate command is spitting back access-denied problems about the /var/run/slocate.db file to the regular users. The UID is set to 'root' currently, and the GID is 'slocate'. Apparently there is no 'slocate' user, only a group. What user is the slocate.db supposed to be? Maybe this is a case for chmod 4640? (Well that didn't work)

Hmm... deleting the old database and updatedb'ing anew didn't fix it either. Must be inheriting some bad permissions?

sigsegv · 04-06-2005, 04:50 PM

Investigate the --setperms and --setugids options to RPM...

Something like:

for RPM in `rpm -qa`; do rpm --setperms $RPM; rpm --setgids $RPM; done

Edit: Fixed the loop. That's what happens when I post things without testing them

Wujen · 04-06-2005, 05:20 PM

Quote:

Originally posted by sigsegv
Investigate the --setperms and --setugids options to RPM...

Something like:

for RPM in `rpm -qa`; do rpm --setperms --setgids ${RPM}; done

Thank you much sigsegv! That solved both problems above and gives me hope for ferreting out any other little things that pop up!

rpm --setperms slocate-2.7;rpm --setguids slocate-2.7 got me my locate command back
and
rpm --setperms coreutils-5.2.1-31.i386;rpm --setguids coreutils-5.2.1-31.i386 got me the su command back!

Nice little loop, btw. Using both --options at the same time gave me a bunch of 'chmod: invalid mode string' errors, so I broke it down into two loops. Thanks again!