Why don't you use "init=/bin/bash rw" ?? Which mounts the root filesystem writeable and starts a shell?

dracut should not be needed for that.

Comments from ablum:

It seems that when you pass 'init=/bin/bash' to the kernel in GRUB and 
change any file, that file will end up with file_t as context.  Here is one
of the other files I changed:

-rw-r--r--. root root system_u:object_r:file_t:s0
/lib/systemd/system/rescue.service

So, the real problem is not so much a selinux issue, per se.  It's more of
a catch-22 caused by the move to sulogin in rescue.service vs. sushell.
You are trying to change the root password [b/c you don't know it] but you
are being prompted for it by sulogin.  When you work around this with
'init=/bin/bash' you end up with files with file_t context which then
causes some problems.

So, the question I think we are asking is, what should be the recommended
way to reset the root password when you do not have physical media ?

1. Boot with 'init=/bin/bash' argument
2. mount -o remount,rw /
3. passwd root
4. touch /.autorelabel
5. Restart the system.  The system relabels and then reboots
automatically.

Doesn't this make the assumption that the customer has maintained file
context mapping definitions across the whole system [via semanage
fcontext] ?

I guess it just makes me kind of nervous.  What if the cu has altered
file contexts for a specific service without semanage ?  Couldn't an
autorelabel cause a problem in those cases ?

Could we be more specific with which files need their contexts
relabeled ? In the procedure given by Paul Frields, /etc/shadow would be one.

Regards, 

-- Andrew Blum, RHCA RHCX GSS Training Content Developer

I'll reassign this to distribution.

If you want a pw-less shell, then introducing a sushell.service might make more sense, than dracut changes.

Bill?

I guess we could have a disabled service for this, but it seems weird to me to require the administrator to set up a specific service to make their system less 'secure' in this way - if they're setting up the system in this way, they're likely able to change their password correctly.

WRT SELinux, doesn't load_policy work from init=/bin/bash?

I tried to use load_policy as Bill suggested in comment #7 and files seem to be labeled correctly.

So if I use Andrius' steps:

1. Boot with 'init=/bin/bash' argument
2. /usr/sbin/load_policy
3. mount -o remount,rw /
4. passwd root
5. Restart the system. System boots and user is able to login correctly in enforcing mode.

Is this sufficient solution?

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

This is probably sufficient, but let's wait to see what customers say about this. Obviously a new dracut module would be the best experience, but let's see what people say.

I've updated:

https://access.redhat.com/site/solutions/1192

to reflect this.

Yes, load_policy worked for me without having to reboot or relabel.

Should we use the -i option with load_policy ? Passing no argument returns:

"Can't load policy: No such file or directory"

Also, shouldn't we also remount root to read-only after the change before killing the bash shell..maybe that's being too cautious ?

1. Boot with 'init=/bin/bash' argument
2. /usr/sbin/load_policy -i
3. mount -o remount,rw /
4. passwd root
5. mount -o remount,ro /
6. Restart the system. System boots and user is able to login correctly in enforcing mode.

Thanks for your help.
--
Andrew

Is this issue solved? I am not sure what else I can do from distribution component point of view.

Setting needinfo on cpelland, my replacement in GSS.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days