Re: Odd messages during bootup from gdm

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

 



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
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux