RHEL 5 SELinux initscripts problem
By Jon Jensen
April 22, 2011
I ran into a strange problem updating Red Hat Enterprise Linux 5 a few months ago, and just ran into it again and this time better understood what went wrong.
The problem was serious: After a yum upgrade of a RHEL 5 x86_64 server with SELinux enforcing, it never came back after a reboot. Logging into the console I could see that it was stuck in single user mode because there were no init scripts! Investigation showed that indeed the initscripts package was completely missing.
I searched on bugzilla.redhat.com looking for any reported problems and didn’t find any. I reinstalled initscripts, rebooted, and the server was fine, but it was not happytimes to have that unexpected downtime.
Tonight I ran into the problem again, this time on a build server where downtime didn’t matter so I could investigate more leisurely.
The error from yum looked like this (the same problem affected the screen package as affected initscripts):
Downloading Packages:
screen-4.0.3-4.el5.i386.rpm | 559 kB 00:00
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
groupadd: unable to open group file
error: %pre(screen-4.0.3-4.el5.i386) scriptlet failed, exit status 10
error: install: %pre scriptlet failed (2), skipping screen-4.0.3-4.el5
Updated:
screen.i386 0:4.0.3-4.el5
Complete!
# cat /selinux/enforce
1
The way I dealt with this initially was to temporarily disable SELinux enforcing, update the package, then reboot (to also load a kernel update):
# setenforce 0
# yum -y upgrade
# shutdown -r now
But following up on the specific error message showed:
# ls -lFaZ /etc/group
-rw-r--r-- root root system_u:object_r:file_t:s0 /etc/group
Aha! The SELinux context is wrong. Given that this has happened a couple of different machines, I’m guessing some past upgrade broke the context. What should it be? Let’s check /etc/passwd for reference:
# ls -lFaZ /etc/passwd
-rw-r--r-- root root system_u:object_r:etc_t:s0 /etc/passwd
That’s confirmed the correct context for /etc/group on another working server. To fix:
# chcon system_u:object_r:etc_t:s0 /etc/group
Then the updates proceed fine. It would be nice to find out what past action set the context wrong on /etc/group.
hosting linux redhat security selinux
Comments