629257 – sulogin fighting with login shell for input when 'init s' is run

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 629257 - sulogin fighting with login shell for input when 'init s' is run

Summary: sulogin fighting with login shell for input when 'init s' is run

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	initscripts
Sub Component:
Version:	6.0
Hardware:	All
OS:	Linux
Priority:	low
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	initscripts Maintenance Team
QA Contact:	qe-baseos-daemons
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2010-09-01 12:38 UTC by Les F
Modified:	2012-03-01 15:57 UTC (History)
CC List:	4 users (show)
Fixed In Version:	initscripts-9.03.18-1.el6
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2011-05-19 13:51:14 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)
Screen shot of sulogin and shell prompts (98.04 KB, image/jpeg) 2010-09-01 12:38 UTC, Les F	no flags	Details
stop tty and serial on runlevel 's' (966 bytes, patch) 2010-12-03 14:31 UTC, Petr Lautrbach	no flags	Details \| Diff
View All

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2011:0647	0	normal	SHIPPED_LIVE	initscripts bug fix and enhancement update	2011-05-19 09:37:27 UTC

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 9 Petr Lautrbach 2010-12-06 17:16:26 UTC

http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=7ea0e422f14deb956886c7fc7c13eb4e6ed3e57c

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

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