systemd: Failed to initialize SELinux context: Permission denied
John.Florian at dart.biz
John.Florian at dart.biz
Fri Dec 7 19:53:34 UTC 2012
Daniel J Walsh <dwalsh at redhat.com> wrote on 12/07/2012 14:40:55:
>
> -----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-----
Believe it or not, I had enough ssh history in konsole on that machine to
scroll back and see where I was doing the upgrade and lo and behold, it
was on -59 at the time.
Would it make sense to capture the policy version in the audit.log
alongside those AVCs? Seems like that would be helpful when reviewing
them. Or would it be useless without some sort of "tainted" flag like the
kernel uses to indicate when the policy had been augmented in some way?
--
John Florian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/test/attachments/20121207/4b4c1191/attachment.html>
More information about the test
mailing list