Tony Nelson wrote:
At 11:51 PM -0400 5/4/06, Jim Cornette wrote:
Tony Nelson wrote:
SELinux must be active but not enforcing for it to relabel.
During the development testing phase, selinux was in a state where
selinux could not even be in permissive mode for booting a kernel. I
relabeled the system with SELinux completely disabled and in runlevel 1
and was able to boot successfully after relabeling the system.
you could argue that sonce the system goes into relabelling once mode is
switched from disabled to enabled, either permissive or enforcing,
relabeling was successful only because of round two relabeling.
Did you relabel with "touch /.autorelabel ; reboot", or with fixfiles etc?
Since booting the system was impossible with SELinux in any mode, I used
fixfiles relabel. Using touch /.autorelabel still would not allow for
the system to boot. (Kernel panic)
Since Gene seems to had success using different methods, his system must
be in that bad of a state.
If my understanding is correct. relabeling is file system related and
selinux does not need enabled in order to add content to the file
system. In order to honor the content within the labled file system,
selinux must be active.
My experience was that if SELinux is disabled it won't do anything,
including relabel on boot. I did "touch /.autorelabel" and rebooted with
"selinux=0" on the linux command line, and nothing happened; I tried again
with "enforcing=0" instead and the relabel happened. I haven't tried
restorecon / setfiles / fixfiles.
The behavior sounds rational since selinux is disabled, it should
disable the presence of /.autorelabel
If SELinux is active during relabeling, it could prevent file content to
be added to the filesystem. SELinux governs by the rules written to the
file system, if I'm on cue.
SELinux has two levels of, umm, "disablement". In Permissive mode it is
still active and will note any denials in the log without actually
preventing the access, or it can be disabled, in which case it can't do
anything.
You would think that permissive mode would only log failures and allow
all actions without restriction. This was not the case with several
testers during the testing phase. Even in permissive, some actions were
denied and successful relabeling was hindered by denials of actions.
touch /.autorelabel followed by a reboot with enforcing=0 as a boot
parameter is probably the best way to relabel the system successfully.
Jim
--
Plate voltage too low on demodulator tube
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
