Problem booting under F16

[JB]

Daniel J Walsh <dwalsh <at> redhat.com> writes:

> 
> 
> On 12/07/2011 03:14 AM, JB wrote:
> > JB <jb.1234abcd <at> gmail.com> writes:
> > 
> >> ...
> > 
> > To make my point clear.
> > 
> > In general, the resuce mode turns all services off for the purpose
> > of preserving the original troubled environment (machine state) and
> > preventing any worsening of it until it can be investigated or
> > fixed.
> > 
> > So it seems a rescue mode should not allow execution of selinux
> > relabeling right before it, under any circumstances.
> > 
> > JB
> > 
> > 
> My understanding is when you are in rescue mode SELinux should be
> disabled and no relabeling should take place.  What does happen is the
> flag gets set (/.autorelabel).  So theoretically when you reboot the
> machine with SELinux enabled, the first thing it will do is make sure
> all the labels are correct so SELinux will work properly.   If you see
> a system that you boot in rescue mode trying to relabel, then I would
> guess this is a bug.
> 

OK. We are on the same page with regard to the principle:
In rescue mode SELinux should be disabled and no relabeling should take place.

But the issue is how to enforce it.
You say "should be", but I showed in that Case scenario that I constructed
few posts above that SELinux can be enabled by chance (sysadmin is doing her
job, there are problems, boom, ...), followed by reboot to rescue mode, which
gets preceded by actual relabeling due to SELinux being enabled as above.

I would like to see it enforced "the hard way", so that the principle does not
get violated by chance or even intention (at least easily via selinux config
file or manual entry).

I thought about using unit file directive(s) to do that, making relabeling
serice and emergency or rescue services (targets) mutually exclusive.

I am not an expert on systemd :-) but it seems that 
  Conflicts=
and
  ConflictedBy=
can do the job.

Can that be done ?

JB