Bug 1476015 - If mcstrans is active, systemd-logind fails to start
If mcstrans is active, systemd-logind fails to start
Status: NEW
Product: Fedora
Classification: Fedora
Component: libselinux (Show other bugs)
26
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Petr Lautrbach
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-27 16:33 EDT by Göran Uddeborg
Modified: 2017-07-27 16:33 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Göran Uddeborg 2017-07-27 16:33:13 EDT
Description of problem:
Since some time back, two of our machines have had problems booting.  Some of the time the systemd-logind services fails with an error message, other times it works.

I've tried to understand what is going on for quite some time.  To make a long story short, I see what I believe is a problem in libselinux.

The problem systemd-logind encounters is an SELinux denial when talking via DBus with systemd itself.  If the mcstrans.service starts up before systemd-logind.service, the following check is logged by systemd:

jul 27 20:38:05 freddi systemd[1]: SELinux access check scon=system_u:system_r:systemd_logind_t:SystemLow tcon=system_u:system_r:init_t:s0 tclass=system perm=status path=(null) cmdline=/usr/lib/systemd/systemd-logind: -13

Note in particular, that the source context has "SystemLow" as its category, while the target context has "s0".  As can be seen, this check fails (-13), the request from systemd-logind is denied, and the service fails.  If, on the other hand, systemd-logind gets started before mcstrans, then the check looks like this:

jul 27 20:39:05 freddi systemd[1]: SELinux access check scon=system_u:system_r:systemd_logind_t:s0 tcon=system_u:system_r:init_t:s0 tclass=system perm=status path=(null) cmdline=/usr/lib/systemd/systemd-logind: 0

Here, the source context also has "s0" as its category, and then the access is allowed (0).  Systemd-logind starts as expected.

The check is implemented as a call of selinux_check_access.

What makes me believe this is a bug in libselinux is that "s0" and "SystemLow" are actually the same thing.  Thus, I would have expected the call of selinux_check_access would give the same result regardless of which notation is being used.

That said, I don't fully understand what is going on here.  I tried to create a simple reproducible case, a small program only calling selinux_check_access with the two contexts.  That DOES work as expected, it accepts a combination of SystemLow and s0 in its arguments.  There is something special in the context of systemd (pid==1) which makes it fail there, but I'm not clear on what.

Have I perhaps misunderstood things?

Note You need to log in before you can comment on or make changes to this bug.