Bug 895860

Summary:

"selinux=0" for installation is not transferred to the installed system

Product:

[Fedora] Fedora

Reporter:

Dr. Tilmann Bubeck <tilmann>

Component:

anaconda

Assignee:

Chris Lumens <clumens>

Status:

CLOSED CURRENTRELEASE

QA Contact:

Fedora Extras Quality Assurance <extras-qa>

Severity:

high

Docs Contact:

Priority:

unspecified

Version:

CC:

dracut-maint, g.kaviyarasu, harald, johannbg, jonathan, lnykryn, metherid, mschmidt, msekleta, notting, pavel.starek, plautrba, psimerda, sbueno, sherman.s.wang, systemd-maint, vanmeeuwen+fedora, vpavlin

Target Milestone:

---

Keywords:

Reopened

Target Release:

---

Hardware:

Unspecified

OS:

Unspecified

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2013-04-10 14:34:06 UTC

Type:

Bug

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
dmesg after running with enforcing=0	none

Description Dr. Tilmann Bubeck 2013-01-16 07:14:19 UTC

Description of problem:
Unable to use emergency mode on a freshly installed Fedora 18 if selinux is enabled (which is the default). I get the following errors:

Welcome to emergency mode! Type "systemctl default" or ^D to enter default mode.
Type "journalctl -b" to view system logs. Type "systemctl reboot" to reboot.
Give root password for maintenance
(or type Control-D to continue): XXXXXX
sulogin: /bin/bash: exec failed: Permission denied
sulogin: /bin/sh: exec failed: Permission denied
Login inkorrekt

Give root password for maintenance
(or type Control-D to continue): XXXXXX


Version-Release number of selected component (if applicable):
dracut-024-18.git20130102.fc18

How reproducible:
Always

Steps to Reproduce:
1. Install Fedora 18
2. Reboot
3. Enter "emergency" at the boot prompt.
  
Actual results:
Unable to login. See above.

Expected results:
Login

Additional info:

Comment 1 Harald Hoyer 2013-01-17 13:06:34 UTC

This is _not_ in the initramfs. This is already in the real root.

Comment 2 Michal Schmidt 2013-01-17 13:44:53 UTC

Could you try this in permissive mode ("enforcing=0") and save any avc denial messages found in dmesg?

Comment 3 Dr. Tilmann Bubeck 2013-01-17 19:14:04 UTC

Created attachment 680456 [details]
dmesg after running with enforcing=0

Comment 4 Dr. Tilmann Bubeck 2013-01-17 19:21:25 UTC

Maybe it is of interest that I started installation of FC18 with selinux=0 as a kernel parameter during PXE booting of FC18 installation?

Comment 5 Michal Schmidt 2013-01-17 19:24:58 UTC

On your system sulogin runs as abrt_helper_t, /usr/bin/bash is file_t. These labels make no sense. Perform a complete relabel.

(In reply to comment #4)
> Maybe it is of interest that I started installation of FC18 with selinux=0
> as a kernel parameter during PXE booting of FC18 installation?

I guess that's the cause indeed.

Comment 6 Dr. Tilmann Bubeck 2013-01-17 19:58:32 UTC

Yes, I verified it. I installed again without using selinux=0 during installation. Now I can use emergency, however I get the following message, but still login:

Give root password for maintenance
(or type Control-D to continue):
sulogin: /root: change directory failed: Keine Berechtigung
Logge ein mit Heimatverzeichnis = ,,/".
bash-4.2#

Therefore 2 points remaining:

1. Fix the above message

2. Fix the situation where installing with selinux=0 and getting a broken system.
   (I use selinux=0 since the introduction of selinux, because I do not like
    selinux. Until recently, this boot parameter was transfered by anaconda
    to the installed system which was then disabling selinux from the beginning.
    This functionality seems to be gone and it only disabled selinux during
    installation leading to the problems above.
    Could you detect this situation and give a appropriate message?

Comment 7 Pavel Stárek (CZ) 2013-02-05 14:16:52 UTC

(In reply to comment #6)
> Yes, I verified it. I installed again without using selinux=0 during
> installation. Now I can use emergency, however I get the following message,
> but still login:
> 
> Give root password for maintenance
> (or type Control-D to continue):
> sulogin: /root: change directory failed: Keine Berechtigung
> Logge ein mit Heimatverzeichnis = ,,/".
> bash-4.2#
> 
> Therefore 2 points remaining:
> 
> 1. Fix the above message
> 
> 2. Fix the situation where installing with selinux=0 and getting a broken
> system.
>    (I use selinux=0 since the introduction of selinux, because I do not like
>     selinux. Until recently, this boot parameter was transfered by anaconda
>     to the installed system which was then disabling selinux from the
> beginning.
>     This functionality seems to be gone and it only disabled selinux during
>     installation leading to the problems above.
>     Could you detect this situation and give a appropriate message?

I agree with Till Bubeck. And I Can confirm this strange bug.

Comment 8 Pavel Šimerda (pavlix) 2013-02-05 14:40:36 UTC

(In reply to comment #7)
> > 2. Fix the situation where installing with selinux=0 and getting a broken
> > system.
> >    (I use selinux=0 since the introduction of selinux, because I do not like
> >     selinux. Until recently, this boot parameter was transfered by anaconda
> >     to the installed system which was then disabling selinux from the
> > beginning.
> >     This functionality seems to be gone and it only disabled selinux during
> >     installation leading to the problems above.
> >     Could you detect this situation and give a appropriate message?
> 
> I agree with Till Bubeck. And I Can confirm this strange bug.

Anaconda should IMO either install a working system, or should refuse to install with an explanation.

Comment 9 Pavel Stárek (CZ) 2013-02-06 11:01:30 UTC

Or, give back option to disable SELinux to firstboot package.(In reply to comment #8)
> (In reply to comment #7)
> > > 2. Fix the situation where installing with selinux=0 and getting a broken
> > > system.
> > >    (I use selinux=0 since the introduction of selinux, because I do not like
> > >     selinux. Until recently, this boot parameter was transfered by anaconda
> > >     to the installed system which was then disabling selinux from the
> > > beginning.
> > >     This functionality seems to be gone and it only disabled selinux during
> > >     installation leading to the problems above.
> > >     Could you detect this situation and give a appropriate message?
> > 
> > I agree with Till Bubeck. And I Can confirm this strange bug.
> 
> Anaconda should IMO either install a working system, or should refuse to
> install with an explanation.

Or give back option to disable SELinux into firstboot package.

Comment 10 Pavel Šimerda (pavlix) 2013-02-06 14:36:24 UTC

(In reply to comment #9)
> > Anaconda should IMO either install a working system, or should refuse to
> > install with an explanation.
> 
> Or give back option to disable SELinux into firstboot package.

I would prefer a clean solution over a workaround :).

Comment 11 Michal Schmidt 2013-02-06 15:22:58 UTC

Chris already fixed it upstream. That's why this BZ is in POST state.

http://git.fedorahosted.org/cgit/anaconda.git/commit/pyanaconda/bootloader.py?id=f0fc233726e1692898cfacf93318959eb45059a8

Comment 12 Pavel Šimerda (pavlix) 2013-02-06 16:16:53 UTC

(In reply to comment #11)
> Chris already fixed it upstream. That's why this BZ is in POST state.
> 
> http://git.fedorahosted.org/cgit/anaconda.git/commit/pyanaconda/bootloader.
> py?id=f0fc233726e1692898cfacf93318959eb45059a8

Thanks. Looks easy.