Jeroen Lankheet wrote:
Bruno Wolff III wrote:
it's ready relabeling or if it's doing anything at all.
Open another terminal while it is running, and check the output of the
`top` command - this only works if you _can_ get to other terminals at
the same time, which I believe is not true in runlevel 1, or when
rebooting.
If you are doing an auto relabel you won't be able to login. The whole
point
of doing the relabel at that point is that it is before init has
started up
processes labelled incorrectly.
What you could do if you want to keep doing stuff through a relabel, is
change to permissive mode, run fixfiles restore /, reboot when its
done, change
back to enforcing mode.
That process I think can still hit some corner cases where files might be
left incorrectly labelled. But you can run a verify afterwards to check.
Thanks for the help so far guys, and sorry for the lousy subject.
I booted into runlevel 1 and saw the relabel doing it's work.
Then I could actually boot my system and login again without having to
disable selinux as a kernel parameter. But selinux was still in
permissive mode.
The SELinux troubleshooter mentioned some alerts; denials and
potentially mislabeled files. So I switched to enforcing mode, and then
immediately all kinds of (more or less expected) problems start. The
system logs me out 10 seconds after being logged in.
So now I'm back in permissive mode.
So the next challenge is that I should 'make the troubleshooter happy'.
But this is the part where my selinux knowledge is falling short.
The attached file contains the troubleshooter alerts.
How do I create a local policy for these selinux denials? I don't know
what the complained files are for.
Regards,
Jeroen.
This is after fixfiles reabel in permissive mode and runlevel 1?
Filing a report with the audit logs and initial cause of the problem and
current browser reports might help with a resolution.
I don't think that SELinux prepared for such a problem, even though it
unintentionally suggested the solution.
Jim
