Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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...
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?
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!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.