Marko Vojinovic <vvmarko <at> gmail.com> writes:
...
>
> Case:
> - I disable selinux
> # cat /etc/sysconfig/selinux ...
> SELINUX=disabled
> - I reboot the system,
> - /.autorelabel created by sys init,
> - I enable selinux again,
> - I reboot with intention to boot rescue mode kernel (obviously because I
> assume there is some problem to fix; it would make sense to boot to the
> same system state that caused me to want it have investigated or fixed,
> without e.g. any potential interruption or fs changes, perhaps from selinux
> doing relabeling), - Selinux jumps in with relabeling (potential
> interference/change to system state as described above, it may not even
> finish its job, and so I am stuck and unable to fix the system, now and
> possibly on next attempt as well).
>
> Do you see a problem here ?
I see a problem with a second-to-last step in your list.
If you have a broken system which needs rescuing, and it has SELinux disabled
to begin with, why would you want to enable it just before getting into
rescue mode?
Yes, indeed, but it is not impossible.
I wanted to re-play (mechanically) a case reflecting Daniel's description.
And it seems to show a weak point.
And if you actually do have a reason to enable it and then rescue the
system,
you'd better let it relabel, or else you are in for a very fun ride with your
rescue operation...
That may be true on the surface, but as I already stated there is a danger
in selinux not finishing or getting stuck, altering system state to be
"rescued" (investigated or fixed).
...
Yes, your other remarks regarding selinux are valid.
JB