systemd: Failed to initialize SELinux context: Permission denied

Daniel J Walsh dwalsh at redhat.com
Fri Dec 7 19:40:55 UTC 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/07/2012 11:26 AM, John.Florian at dart.biz wrote:
> Daniel J Walsh <dwalsh at redhat.com> wrote on 12/07/2012 10:46:11:
>> 
>> On 12/07/2012 08:44 AM, Bruno Wolff III wrote:
>>> On Fri, Dec 07, 2012 at 08:22:10 -0500, John.Florian at dart.biz wrote:
>>>> 
>>>> Thinking selinux might be preventing the relabel from happening (?!?)
>>>> I rebooted with selinux=0 so that I could reconfig
>>>> /etc/sysconfig/selinux having SELINUX=permissive, touched
>>>> /.autorelabel and rebooted again. This time I saw the relabel process
>>>> do its thing and trigger a reboot.  I then went back to reconfig
>>>> /etc/sysconfig/selinux having SELINUX=enforcing, rebooted and all
>>>> seemed well, finally.
>>> 
>>> The autorelabel is supposed to happen early in the boot process and I
>>> think it is supposed to work even if you system normally comes up in
>>> enforcing mode. So that sounds like a bug.
>>> 
>>> (You can come up in permissive mode using the enforcing=0 kernel
>>> parameter. This is a bit more convenient in some cases for a one time
>>> boot, than changing the selinux configuration.)
>>> 
>>> This is generally the safeest way to relabel as you don't want
>>> processes that started with the wrong context creating more incorrectly
>>> labelled files while you are trying to fix things up (with say
>>> restorecon).
>>> 
>>>> So, I'm all good now, but there may be some bugs in that "relabel
>>>> should happen automatically" bit. -- John Florian
>> Yes systemd is supposed to set the machine into permissive mode for the 
>> relabel, but I guess if the machine is totally mislabeled, systemd might
>> be prevented from doing this, although I would figure systemd would be
>> running as the kernel label.  Bottom line this would be difficult to
>> diagnose what happened to force you to relabel in permissive mode. 
>> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment:
>> Using GnuPG with undefined - http://www.enigmail.net/
>> 
>> iEYEARECAAYFAlDCD0MACgkQrlYvE4MpobN0gACeIRh+3rBTIXX/GVvxxIrMnvUq 
>> 1EUAoNfsFpd+zYOiPq9h/+fXol6j3mLO =kYu4 -----END PGP SIGNATURE-----
> 
> 
> I agree this would be hard to diagnose.  I doubt I could reproduce the
> situation given all this poor system has been through.  That and I'm
> already up to my ears in alligators trying to port our software stack over
> to what's becoming F18.
> 
> As I stated, it's no longer a problem for me, so I'm happy.  I just wanted
> to make sure those who would want to know had been informed.
> 
> -- John Florian
> 
> 
If you have a selinux-policy version of 57,58,59 it could have also failed on
the relabel in enforcing mode, since there was  a major bug in policy that
should be fixed by -60.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDCRkYACgkQrlYvE4MpobNVEwCg3sx2OlPipwq2YHlS+fxsozCb
ayUAn2r56PioTL8Swc0nG9cglnpOT3tY
=Bds9
-----END PGP SIGNATURE-----


More information about the test mailing list