[rhelv6-list] setuid helper permission??? - RESOLVED!

[Robert G. (Doc) Savage]

Three weeks ago I ran a newly-edited script that was missing one
critical character. My first indication that something was wrong was
when all attempts to "su -" to root failed with a wrong password error.
I rebooted to single user mode, ran passwd, then rebooted again. I knew
I had serious trouble when it booted to a black screen.

I hard reset, rebooted to single user mode again. In retrospect it seems
a miracle it could do that because I found everything -- every file,
every directory -- was owned by me:me. With more than 2,500 packages
installed, recovery would take time: three weeks, with help.

Steve Pritchard, a local friend who maintains several hundred Fedora
hardware packages, helped me cob together a script that tried to use rpm
to restore proper ownerships:

# cat rpmowners.sh
#!/bin/sh
rpm -qalv  | grep -v '^(contains no files)$' | grep -v '^l' \
	| while read perm nlink user group size month day time filename ; do
	chown -v "$user":"$group" "$filename"
done

After a 24-hour run there were still thousands of files owned by me:me,
but even with several errors I was able to boot to runlevel 3. Progress.
All the soft links in /etc/rc.d/ and below were still owned by me:me, so
I manually re-created those as root:root. That didn't help much.

A close examination of /var/log/messages showed some sort of "setuid
helper" permissions problem. A Google search seemed to point
to /usr/bin/sudo. After posting that info to this list, Hugh Brown told
me there were several other setuid executables besides sudo. He had me
run this script to identify what rpm calls "Mode" problems:

# cat setuid-check.sh
#!/bin/sh
cat /root/rpmlist.txt | while read pkg; do
	echo "########## Testing $pkg ##########"
	rpm -V $pkg | grep -E "^.M"
done | tee rpm-pkg-mode-problems

This identified more than a dozen packages with ownership and/or
permission ("Mode") problems. While it told me there was a problem, it
didn't say what those ownerships and permissions needed to be. So, I
tried reinstalling everything in the RPM database:

# rpm -qa | sort > ~/rpmlist.txt

# cat reinstall.sh
#!/bin/sh
for i in `cat /root/rpmlist.txt` ; do \
	yum -y reinstall $i
done

After that script also ran for 24 hours, the setuid-check.sh script
still showed more than a dozen Mode errors. Yum should have fixed those,
so there's probably a bug in its reinstall option.

Barry Brimer and a couple of others suggested using rpm itself rather
than yum, so for each of those Mode error packages I ran:

# rpm --force --setperms --setugids --replacefiles <pkgname>

After that I tried rebooting to runlevel 5 and got the graphical logon
screen -- Hooray!! But the keyboard and mouse which worked fine at
runlevel 3 were totally inop.

Hugh Brown suggested I try manually starting X from runlevel 3:

# startx -- -logverbose 5

and check /var/log/Xorg.0.log. BINGO! There it was: the haldaemon wasn't
running. That made sense: no haldaemon, no mouse or keyboard. I ran
"chkconfig haldaemon on", rebooted, and Voila!

What killed my system in the first? Whatever you do, try not to make
this mistake in a script:

set LOCAL_USER=me:me
set LOCAL_DEST1=/pub/ScientificLinux/scientific/6.0/
set LOCAL_DEST2=/pub/ScientificLinux/scientific/6.x/
...
cd LOCAL_DEST   <-- ERROR
cd ..
chown -R me:me

See it? The undefined variable "LOCAL_DEST" (not LOCAL_DEST1 or
LOCAL_DEST2) will evaluate to "~" for the user running the script -- in
this case /root. The script promptly cd'd to / and did what it was told.
OH NO!!

--Doc Savage
  Fairview Heights, IL