On Tuesday 06 December 2011 22:16:40 JB wrote: > Daniel J Walsh <dwalsh <at> redhat.com> writes: > > ... > > SELinux relabeling is caused by booting a rescue mode kernel. As soon > > as you boot a system with SELinux disabled, the init system creates > > the /.autorelabel file, so the next time it boots with SELinux it will > > relabel. > > Question: > Are you not setting yourself up for trouble with this /.autorelabel here ? > > 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? 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... This is one of the reasons why I don't like the option to disable SELinux completely. If you leave it in permissive mode, it will keep out of your way while keeping proper file labelling. Thus no problems can arise if you ever want to enforce SELinux again. Disabling SELinux completely makes sense only on HPC clusters and similar, where every bit of CPU time should be squeezed out, where SELinux has a nontrivial CPU/FS footprint, and where security is not an issue so that its footprint is useless. The rule of thumb is --- disable SELinux only on systems where you are absolutely certain that you will never ever ever want to reenable it again. On everything else keep it in enforcing or permissive, and you won't get into inconvenient-relabeling-time problems. HTH, :-) Marko -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
