Paul Howarth wrote:
On Thu, 2006-05-04 at 23:06 -0500, Gene Heskett wrote:
Jim Cornette wrote:
Tony Nelson wrote:
SELinux must be active but not enforcing for it to relabel.
____________________________________________________________________
TonyN.:' <mailto:tonynelson@xxxxxxxxxxxxxxxxx>
' <http://www.georgeanelson.com/>
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.
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.
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.
Jim
I'll try it one more time, with it enabled. But it seems to me that if
restorecon cannot access the config file, and here I'm ASSUMING that the
config file in question is /etc/selinux/config, then I doubt seriously
that restorecon can even begin to rectify the problems.
FWIW, here is an ls -lZa of /etc/selinux/config:
-rw-r--r-- root root system_u:object_r:file_t
/etc/selinux/config
Is that anywhere near correct? Editing has always been done with vim,
as root.
If the system has been relabelled properly, there should be nothing
labelled file_t I believe.
Try to get SELinux booting in permissive mode, by having:
SELINUX=permissive
SELINUXTYPE=targeted
in /etc/sysconfig/config
It is.
Try to fix the labels on /etc/selinux:
# restorecon -Rv /etc/selinux
Done
Reboot, and you should get:
# getenforce
Permissive
Did
When that's working, then try:
# touch /.autorelabel
and reboot again.
And i get, during the reboot, a
*********warning, relabeling requires a targeted yadda yadda***************
********and will take a long time******************
all typed from memory as this message never makes it to the logs, but
lemme look one more time... Yup, this is all thats logged:
May 5 08:03:35 diablo kernel: audit(1146834182.576:2): avc: denied {
search } for pid=515 comm="pam_console_app" name="var" dev=hda5 ino=32
08129 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255
tcontext=system_u:object_r:file_t:s0 tclass=dir
and it instantly proceeds with the reboot. No pause in the procedure, none.
Look, I know this thing means well, but if its going to be such a pain
in the ass, then I'm afraid I'll just have to turn it off and forget
about it.
Whomever is the project manager, really needs to get the tools written
so that A: the manpage tells one how to fix things in a manner that
actually works. And B: since its our machine, tell us in plain english
what needs fixed when something does need fixed.
Right now, restorecon seems helpless because it doesn't like the lines
19 and 33 in the targeted file contexts file, so it refuses to do
anything. Or did the last time I tried to run it. Now its not showing
that error after this last reboot. By now, this box has been rebooted
so many times I've made icons for both shutdown and reboot! Any windows
box that needed to be rebooted this many times in an hour would get
tossed in the recycle bin!!!!!
I would hope that there is nothing labelled file_t after that.
Is there a command that will survey the system and find such?
Paul.
--
Cheers, Gene
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
