Bug 176839 - selinux-policy-targeted botched?
selinux-policy-targeted botched?
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
: Security
Depends On:
  Show dependency treegraph
Reported: 2006-01-03 11:00 EST by Horst H. von Brand
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-05 09:48:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
audit log (4.08 MB, text/plain)
2006-01-03 22:50 EST, Jim Cornette
no flags Details
dmesg after relabeling (14.69 KB, text/plain)
2006-01-04 19:01 EST, Jim Cornette
no flags Details

  None (edit)
Description Horst H. von Brand 2006-01-03 11:00:56 EST
Description of problem:
SELinux is set to enforcing, policy is targeted.

When booting the new kernel after updating today (kernel, selinux, etc) the
system won't boot. It goes to system maintenance. Giving the root password only
/ is mounted (it looks like the contexts for the LVM devices are incorrect, so
it can't access them). Only disabling SELinux completely (selinux=0 on the
kernel line) seems to be able to continue. "fixfiles relabel" doesn't fix the

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Boot
Actual results:

Expected results:

Additional info:
Comment 1 Daniel Walsh 2006-01-03 11:52:43 EST
Could you check to see if the problem is with libsetrans.

Edit the /etc/selinux/targeted/setrans.conf and uncomment the disable line and
see if it boots.

A new version of libsetrans is available at
Available on ftp://people.redhat.com/dwalsh/SELinux/Fedora/x86_64

Comment 2 Tom London 2006-01-03 12:38:24 EST
The above edit to setrans.conf 'fixes' this for my x86 system too.

[BTW, I could boot by using 'enforcing=0' instead of 'selinux=0']
Comment 3 Daniel Walsh 2006-01-03 12:49:21 EST
Ok try the new version of libsetrans available on 


And you can turn back on translations.
Comment 4 Tom London 2006-01-03 13:17:19 EST
libsetrans-0.1.14-1 and enabling translations WFM.

Comment 5 Bojan Smojver 2006-01-03 16:59:16 EST
Same problem on i686 here. I'll try the new packages and I'll report back.
Comment 6 Bojan Smojver 2006-01-03 17:09:51 EST
A little bit better, but now I have a problem with fixfiles. It won't run - it
just prints the usage for setfiles instead.

I noticed that policycoreutils got updated today as well...
Comment 7 Jim Cornette 2006-01-03 22:44:22 EST
I don't know if the arch as 64-bit matters. I ran into several packages that
would download via yum but not actually install. I had to drop to selinux=0
single and run rpm -Uvh from the packages contained in the cache for yum.
Audit log attached.
I did not relabel my system yet. I started the network service and ran yum from
single user mode and several packages would not install but are available.
Audit log will be attached next.

Updated Packages
hpijs.i386                               1:0.9.7-6              development
hplip.i386                               0.9.7-6                development
libsane-hpaio.i386                       0.9.7-6                development
net-snmp-libs.i386                       5.3-1                  development
Comment 8 Jim Cornette 2006-01-03 22:50:55 EST
Created attachment 122752 [details]
audit log

kdeutils-3.5.0-2.i386.rpm  kdeutils-devel-3.5.0-2.i386.rpm
and some php elements seem to be causing problems.

I hope the log helps. System only had missing files from mozilla and cups that
were discussed on the test-list.

Comment 9 Jim Cornette 2006-01-04 19:01:28 EST
Created attachment 122800 [details]
dmesg after relabeling

After updating system, dropping to runlevel 1 and verifying packages installed
using 2.6.15-1.1819_FC5, I relabeled the system and rebooted with minor errors
related to /dev/hda6.
Filesystem	     1K-blocks	    Used Available Use% Mounted on
/dev/hda2	      16425032	 4878912  10698292  32% /
/dev/hda1		101086	   12210     83657  13% /boot
/dev/shm		322364	       0    322364   0% /dev/shm
/dev/hda3	       9920624	  978660   8429896  11% /home
/dev/hda6	      10605128	  261408   9796308   3% /var

# rpm -qa |grep policy

The system seems to be mostly successful. Errors submitted for remaining
Comment 10 Bojan Smojver 2006-01-05 16:25:43 EST
Indeed today's stuff does work. However, the stangest thing happened on
filesystem relabel during boot (forced by switch to SELinux enforcing) - my
notebook rebooted in the middle of it. File systems were dirty after the reboot,
so it wasn't a "planned" event. Later on, I relabeled from runlevel 5 successfully.

No idea what caused this. Kernel bug?

Note You need to log in before you can comment on or make changes to this bug.