Bug 629257

Summary: sulogin fighting with login shell for input when 'init s' is run
Product: Red Hat Enterprise Linux 6 Reporter: Les F <lesf.999>
Component: initscriptsAssignee: initscripts Maintenance Team <initscripts-maint-list>
Status: CLOSED ERRATA QA Contact: qe-baseos-daemons
Severity: medium Docs Contact:
Priority: low    
Version: 6.0CC: azelinka, mfuruta, notting, plautrba
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: initscripts-9.03.18-1.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-19 13:51:14 UTC Type: ---
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
Screen shot of sulogin and shell prompts
none
stop tty and serial on runlevel 's' none

Description Les F 2010-09-01 12:38:44 UTC
Created attachment 442400 [details]
Screen shot of sulogin and shell prompts

Description of problem:

when sulogin is set to force root password to go to single user
init 1 works fine
init s seems to have sulogin and current shell fighting for input at the same time.

I realize the proper way to go single user is now "init 1" but wanted to make sure if I tell the system to request root password for single user that it does so in all cases.

I am assuming this is an upstart problem..

Version-Release number of selected component (if applicable):
upstart-0.6.5-6.1.el6.x86_64

How reproducible:
Simple RHEL6 beta refresh 2 load.

Steps to Reproduce:
1. In /etc/sysconfig/init
   change "SINGLE=/sbin/sushell" to "SINGLE=/sbin/sulogin"

2. run level 3, at root prompt type 'init s'


  
Actual results:
Login shell is still accepting input, the sulogin is trying to get the root password.  Password echoes to screen, both procs are taking pieces of what you type. At this point the system is pretty much useless as part of what you type goes to the login shell, and part goes to sulogin.

Expected results:
sulogin should have full control at this point asking you for root password.
Your login shell should not be accepting input as well.


Additional info:

init 1 works fine.
I realize that init s is no longer the proper way to go single user but I would assume for security reasons if you have sulogin enabled then you should not be able to simply get around it by typing init s.  At my job this is a requirement for our systems.

Screen shot attached

This was not the same behavior in other versions of RHEL.

Comment 2 Petr Lautrbach 2010-09-01 13:07:59 UTC
from telinit(8):

     RUNLEVEL  may also be S or s which will place the system directly into single-user mode without actually stopping processes first, you probably won’t want that.


That means if you run 'init s' from running system, nothing (included actual shell, gettys, ...) will be stopped and only $SINGLE will be exec-ed on console.

'init 1' first stops services (gettys, daemons, ...) and after that itruns 'init S'. 

Setting $SINGLE affects both runlevels so you can/should use init 1.

Comment 3 Les F 2010-09-01 16:52:19 UTC
I guess I can't see the functionality of init s anymore then.   
Even if you leave SINGLE defined as /sbin/sushell  (the default)
dropping into init s basically leaves that session useless.

You still end up with sushell and bash both trying to grab input
from the console and no commands will work.

Again, i realize the man page warns you about it, but is it appropriate
to allow a command to screw up your console like it does?

I am thinking about the fact that a lot of 'old' unix types always used
init s and up thru RHEL5 it worked fine (along with init 1).  Now if you
do an init s, you end up with either a shell & login prompt fighting each
other or you end up with bash and sushell fighting for input, either case
is not pretty or usable.

Comment 4 Bill Nottingham 2010-09-02 14:03:16 UTC
s|S is shorthand, mainly to be used as the runlevel passed on the kernel command line.

The difference between RHEL 5 and RHEL 6 is that the gettys were still stopped in RHEL 5; this may be possible to change for a later RHEL update.

Comment 5 Bill Nottingham 2010-09-02 14:04:07 UTC
If you change /etc/init/tty.conf from:

stop on runlevel [016]

to

stop on runlevel [S016]

does it behave more like you'd expect?

Comment 6 Les F 2010-09-02 14:18:05 UTC
Yes ... 

I may just tweak that as part of the postinstall 

Thanks!
Les

Comment 8 Petr Lautrbach 2010-12-03 14:31:01 UTC
Created attachment 464579 [details]
stop tty and serial on runlevel 's'

same change as for tty.conf is needed for serial.conf

Comment 11 Les F 2011-04-04 16:18:21 UTC
Looks like you also need to add 's' (little s) as well to that list
of runlevels...

Comment 13 errata-xmlrpc 2011-05-19 13:51:14 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0647.html