[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: kernel panic after policy update failure



On Mon, 2004-04-05 at 13:05, Gene Czarcinski wrote:
[...] snip
> 
> Experience:  It is a bit "cleaner" to boot enforcing=0 rather than selinux=0 
> (even in single user mode) when you are doing this to fix 
> policy/policy-sources.  Installing/reinstalling these rpms will get a bit 
> confused if selinux is not running.
> 

I'm going to agree with Gene here.  In the process of my testing both
the enforce=0 and selinux=0 kernel args (with no policy file), I managed
to get myself into a state whereby I couldn't boot.  It looked like a
corrupt filesystem, but after fscking, I still couldn't boot until I did
enforce=0 on the kernel args again.  

Syslog revealed the following:

Apr  5 20:20:57 pontifex kernel: audit(1081196423.162:0): avc:  denied 
{ read } for  pid=1 exe=/sbin/init name=utmp dev=hde2 ino=81925
scontext=system_u:system_r:init_t tcontext=system_u:object_r:file_t
tclass=file
Apr  5 20:20:57 pontifex kernel: audit(1081196423.162:0): avc:  denied 
{ lock } for  pid=1 exe=/sbin/init path=/var/run/utmp dev=hde2 ino=81925
scontext=system_u:system_r:init_t tcontext=system_u:object_r:file_t
tclass=file
Apr  5 20:20:57 pontifex kernel: audit(1081196426.505:0): avc:  denied 
{ read } for  pid=51 exe=/usr/bin/rhgb name=mtab dev=hde2 ino=561287
scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:file_t
tclass=file
Apr  5 20:20:57 pontifex kernel: audit(1081196426.505:0): avc:  denied 
{ getattr } for  pid=51 exe=/usr/bin/rhgb path=/etc/mtab dev=hde2
ino=561287 scontext=system_u:system_r:rhgb_t
tcontext=system_u:object_r:file_t tclass=file

I poked at this a bit, then ran a fixfiles.  I'm assuming I created or
updated files without labels on them when I booted 'selinux=0'?  Boots
fine with enforcing on afterwards.  <whew> :)

At any rate, both enforcing=0 and selinux=0 do indeed now permit you to
boot and fix things when your policy file is missing.  Having to resort
to a rescue disk was not a good option. 

Nice work!

- J. Scott Farrow
jsfarrow comcast net




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]