Bug 692573 - SELINUX=disabled in /etc/selinux/config causes failure to boot; libselinux lies to systemd about SELinux state
SELINUX=disabled in /etc/selinux/config causes failure to boot; libselinux li...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: libselinux (Show other bugs)
15
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
AcceptedBlocker
: Reopened
: 692602 693410 (view as bug list)
Depends On:
Blocks: F15Beta/F15BetaBlocker
  Show dependency treegraph
 
Reported: 2011-03-31 11:29 EDT by Michał Piotrowski
Modified: 2011-05-26 07:12 EDT (History)
27 users (show)

See Also:
Fixed In Version: libselinux-2.0.99-4.fc15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-04-08 22:11:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
systemd-v21 failed boot (186.15 KB, image/jpeg)
2011-03-31 11:30 EDT, Michał Piotrowski
no flags Details

  None (edit)
Description Michał Piotrowski 2011-03-31 11:29:22 EDT
Description of problem:
My system refuses to boot, see attachment. I don't use SELinux, so it must be something else. Rootfs appears to be mounted ro


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Michał Piotrowski 2011-03-31 11:30:05 EDT
Created attachment 489137 [details]
systemd-v21 failed boot
Comment 2 Michal Schmidt 2011-03-31 11:47:06 EDT
Interesting that it complains about the read-only filesystem when touching /var/lock/subsys/local because /var/lock is supposed to be a bind-mount of /run/lock which is a tmpfs.
Something important must have failed earlier than what we see on the screenshot.
Can you at least boot with the "emergency" boot parameter?
Comment 3 Michał Piotrowski 2011-03-31 11:53:17 EDT
Ok, source of the problem was SELinux that is not installed on my system at least I thought so.

I tried emergency and emergency.target as boot parameters but it did not work.

I'll check that dirs.
Comment 4 Michał Piotrowski 2011-03-31 11:57:56 EDT
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
tmpfs on /var/run type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
tmpfs on /var/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)

seems to be ok
Comment 5 Michal Schmidt 2011-03-31 12:46:46 EDT
(In reply to comment #3)
> Ok, source of the problem was SELinux that is not installed on my system at
> least I thought so.

Now I am confused. Please state clearly what SELinux state your system is using (disabled, permissive, or enforcing).

> I tried emergency and emergency.target as boot parameters but it did not work.

It's simply "emergency". If you want to be verbose, the equivalent is "systemd.unit=emergency.target".
How exactly did it not work? What was the result?
Comment 6 George Lebl 2011-03-31 12:49:44 EDT
I am seeing this boot failiure as well.  Updated everything yesterday.  After
update the system already hung on trying to reboot.  Then it hung on boot.  It
seemed to hang at different points, with screens similar as above, though the
graphics would sometimes get messed up.  When hung the console was still
scrollable, so the system was not hung completely.  Everything is stock really
so selinux is where it is by default.  The system did manage to boot into
"single" and so I downgraded to the last systemd-v20 package (nothing else) and
the system now boots and works fine, so it is definitely the systemd update
that broke.
Comment 7 Michał Piotrowski 2011-03-31 12:54:33 EDT
(In reply to comment #5)
> (In reply to comment #3)
> > Ok, source of the problem was SELinux that is not installed on my system at
> > least I thought so.
> 
> Now I am confused. Please state clearly what SELinux state your system is using
> (disabled, permissive, or enforcing).

It's disabled, but it works... It's a SELinux bug
http://lists.fedoraproject.org/pipermail/test/2011-March/098461.html

> 
> > I tried emergency and emergency.target as boot parameters but it did not work.
> 
> It's simply "emergency". If you want to be verbose, the equivalent is
> "systemd.unit=emergency.target".
> How exactly did it not work? What was the result?

Result was the same as for normal boot - it hunged.
Comment 8 Michal Schmidt 2011-03-31 12:57:07 EDT
(In reply to comment #6)
> Everything is stock really so selinux is where it is by default.

i.e. enforcing. You're seeing bug 692436.
Comment 9 Michal Schmidt 2011-03-31 13:07:24 EDT
(In reply to comment #7)
> It's disabled, but it works... It's a SELinux bug
> http://lists.fedoraproject.org/pipermail/test/2011-March/098461.html

Aha! Thanks for the link. So the problem only appears when SELinux is disabled in /etc/selinux/config but not if "selinux=0" is used.
Comment 10 Michał Piotrowski 2011-03-31 14:23:55 EDT
Problem with SELinux may be related to missing /etc/sysconfig/selinux link
http://lists.fedoraproject.org/pipermail/test/2011-March/098469.html

In any case, IMO this problem should be marked as duplicate of 692436 bug.
Comment 11 Michal Schmidt 2011-03-31 15:07:58 EDT
*** Bug 692602 has been marked as a duplicate of this bug. ***
Comment 12 Andrew McNabb 2011-03-31 15:17:29 EDT
After upgrading my Fedora 15 Alpha system from systemd 20 to systemd 21, my system stopped booting.  Even systemd.unit=rescue.target and systemd.unit=emergency.target don't work; the only way to get in at all is to set init=/bin/sh. My system has SELINUX=disabled in /etc/sysconfig/selinux, and I have the error messages reported in bug #692602:

Failed to load SElinux policy
Failed to set security context system_u:object_r:sysfs_t:s0 for /sys: Invalid argument
Failed to mount /sys/fs/cgroup/systemd: No such file or directory
Comment 13 Andrew McNabb 2011-03-31 15:20:20 EDT
(In reply to comment #10)
> In any case, IMO this problem should be marked as duplicate of 692436 bug.

I think this is different because this bug deals with the case that SELINUX=disabled but #692436 seems to deal with the case that selinux is enabled.
Comment 14 Adam Williamson 2011-04-01 11:17:24 EDT
If we're using this bug to track SELinux's config file not correctly disabling it, I think we can drop F15Beta. We have a different bug covering the /run-causes-fail-to-boot issue.
Comment 15 H. Peter Anvin 2011-04-01 23:27:25 EDT
I can verify the behavior mentioned in comment #12; same problem here.
Comment 16 H. Peter Anvin 2011-04-01 23:28:31 EDT
... and booting with "selinux=0" does work.
Comment 17 Lennart Poettering 2011-04-04 15:03:43 EDT
I presume this bug is fixed with the new policy 3.9.16-10. Closing.
Comment 18 Andrew McNabb 2011-04-04 15:14:07 EDT
If you had asked, I would have mentioned that it still occurs with 3.9.16-10, which I mentioned in the higher priority bug, #692436.
Comment 19 Andrew McNabb 2011-04-04 16:13:14 EDT
Based on developments in bug #692436, it was determined that the failure to boot in this bug is in fact separate from the failure to boot in the other bug.  Thus, this bug should be a beta blocker after all.
Comment 20 Michal Schmidt 2011-04-04 16:26:50 EDT
I disagree with the classification as a blocker, because:
 - SELINUX=disabled in /etc/selinux/config is not a default configuration
 - an easy workaround is available (add "selinux=0" to boot parameters)
Comment 21 Andrew McNabb 2011-04-04 16:42:56 EDT
(In reply to comment #20)
> I disagree with the classification as a blocker, because:
>  - SELINUX=disabled in /etc/selinux/config is not a default configuration
>  - an easy workaround is available (add "selinux=0" to boot parameters)

My response would be:
 - Disabling SELinux is not a default configuration, but it seems to be quite common.
 - The severity of the bug (complete failure to boot) might make up for the workaround.

But it's not my decision. :)
Comment 22 Rahul Sundaram 2011-04-04 16:54:29 EDT
If some bug is being nominated by anyone as a blocker, it is useful to quote the blocker criteria.    For reference, the requirements are listed at

http://fedoraproject.org/wiki/Fedora_15_Beta_Release_Criteria#Beta_Release_Requirements

Andrew McNabb,  I recommend going through this and quoting the specific requirement that this bug would fail to meet and then the QA team can make the decision.  Thanks.
Comment 23 Andrew McNabb 2011-04-04 17:11:54 EDT
Rahul, if a system fails to boot, then it does not meet beta release requirement 13, 14, 15, 16, 17, 18, 19, 20, or 21, although requirement 18 is arguable because disabling selinux is not default. :)  Of course, requirement 13 is the main one:

13. When booting a system installed without a graphical environment, or when using a correct configuration setting to cause an installed system to boot in non-graphical mode, the system should provide a working login prompt without any unintended user intervention when boot is complete, and all virtual consoles intended to provide a working login prompt should do so

A bug is a blocker if any of three criteria are met, one of which reads, "Bug relates to an unmet Beta Release Requirement".

Is that helpful?
Comment 24 Rahul Sundaram 2011-04-04 17:20:43 EDT
Yes, thanks.
Comment 25 Fedora Update System 2011-04-04 19:40:18 EDT
systemd-23-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/systemd-23-1.fc15
Comment 26 Michal Schmidt 2011-04-04 20:16:41 EDT
systemd-23-1 does not fix this bug.

This is what happens when SELinux is disabled using /etc/selinux/config:
- in selinux_setup() systemd calls:
  selinux_init_load_policy(&enforce)
  This call fails and sets enforce=0 as expected.
- later systemd asks:
  is_selinux_enabled()
  This call returns 1, which is wrong.

The bug is in libselinux in selinux_init_load_policy(). It mount selinuxfs and remembers the mountpoint using set_selinuxmnt(). Later it unmounts selinuxfs, but it does not reset selinux_mnt. is_selinux_enabled() is then confused and takes the non-NULL selinux_mnt as a proof of enabled SELinux.

A fix would be to call fini_selinuxmnt() after umount(SELINUXMNT) in selinux_init_load_policy().
Comment 27 Adam Williamson 2011-04-05 00:22:09 EDT
"Based on developments in bug #692436, it was determined that the failure to
boot in this bug is in fact separate from the failure to boot in the other bug.
 Thus, this bug should be a beta blocker after all."

This is the important point. There are two possibilities.

1) This bug is 'disabling SELinux via configuration file does not work, it causes the system to (try and) boot with SELinux enabled'.

2) This bug is 'disabling SELinux via configuration file causes the system to inevitably fail to boot'.

If 2), this is likely to be a blocker. If 1), it is unlikely. If the system only fails to boot *because there's some other bug making the system fail to boot if SELinux is enabled*, that bug is the blocker, not this one.
Comment 28 Michal Schmidt 2011-04-05 04:34:07 EDT
Adam, 2) is correct.
When SELINUX=disabled is used, SELinux gets in fact disabled correctly, but systemd is mislead to believe the contrary and then it gets very sad when the SELinux-related calls are failing. It fails to mount the essential filesystems and stops booting.
Comment 29 Michal Schmidt 2011-04-05 10:21:38 EDT
*** Bug 693410 has been marked as a duplicate of this bug. ***
Comment 30 Daniel Walsh 2011-04-05 11:26:29 EDT
Fixed in libselinux-2.0.99-3.fc15
Comment 31 Fedora Update System 2011-04-05 12:30:46 EDT
libselinux-2.0.99-4.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/libselinux-2.0.99-4.fc15
Comment 32 Andrew McNabb 2011-04-05 15:51:35 EDT
I have been trying to install my Fedora 15 virtual machine so that I can test this, but right now I'm stuck because bug #693881 is preventing Anaconda from completing an install. In the meantime, would anyone else be able to test the fix in libselinux-2.0.99-4.fc15?
Comment 33 Adam Williamson 2011-04-05 16:17:37 EDT
I already did, and filed feedback.
Comment 34 Fedora Update System 2011-04-05 16:26:16 EDT
Package libselinux-2.0.99-4.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libselinux-2.0.99-4.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/libselinux-2.0.99-4.fc15
then log in and leave karma (feedback).
Comment 35 Mark Struberg 2011-04-06 07:14:10 EDT
I can confirm that libselinux-2.0.99-4.fc15 fixes the problem on x86_64. txs!
Comment 36 Adam Pribyl 2011-04-06 11:23:38 EDT
Looks fixed for me too.
Comment 37 Andrew McNabb 2011-04-06 12:33:36 EDT
I can confirm that this is now fixed for me, too. Thanks to everyone who helped.
Comment 38 James Laska 2011-04-08 14:47:26 EDT
Discussed during the 2011-04-08 blocker review meeting [1].  AcceptedBlocker for beta. Issue fixed in latest libselinux already included in RC1

Moving to VERIFIED based on test feedback.  Thanks all!

[1] http://meetbot.fedoraproject.org/fedora-bugzappers/2011-04-08/f-15-beta-blocker-review.2011-04-08-17.00.html
Comment 39 Fedora Update System 2011-04-08 22:11:37 EDT
libselinux-2.0.99-4.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 40 Maxime Thépault 2011-05-26 02:51:28 EDT
Hi,

I have upgraded my Fedora 14 x86_64 to 15.

I had keeped my old Kernel, and there were many problems, for example "Failed to load SELinux policy." and I obtained only emergency mode.

I installed the following packages that were not present, because I disabled SELinux :

checkpolicy-2.0.23-3.fc15.x86_64.rpm
selinux-policy-3.9.16-24.fc15.noarch.rpm
selinux-policy-targeted-3.9.16-24.fc15.noarch.rpm
policycoreutils-2.0.86-7.fc15.x86_64.rpm

After, I have updated Kernel to latest version :
kernel-2.6.38.6-27.fc15.x86_64.rpm

Now, Fedora 15 boot, but I see on the screen "Failed to load SELinux policy." a short moment.

In the log /var/log/messages I read only :

May 26 08:43:03 kernel: [    0.001101] SELinux:  Initializing.
May 26 08:43:03 kernel: [    8.885976] SELinux:  Disabled at runtime.

set "selinux=0" into kernel args don't change anything.
My /etc/selinux/config contains :

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

Maybe an idea ?
Comment 41 Michal Schmidt 2011-05-26 04:55:35 EDT
(In reply to comment #40)
> I have upgraded my Fedora 14 x86_64 to 15.
> 
> I had keeped my old Kernel, and there were many problems

OK, don't use old kernels.

> After, I have updated Kernel to latest version :
> kernel-2.6.38.6-27.fc15.x86_64.rpm
> 
> Now, Fedora 15 boot, but I see on the screen "Failed to load SELinux policy."
> a short moment.

This message is harmless when SELinux is disabled.

If you're seeing any other problems, please file a separate bug.
Comment 42 Maxime Thépault 2011-05-26 07:12:07 EDT
Thank you, now I am appeased... ;)

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