Bug 40934 - sulogin exits immediatelywhen called in rc.sysinit
Summary: sulogin exits immediatelywhen called in rc.sysinit
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: SysVinit   
(Show other bugs)
Version: 7.1
Hardware: All Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-05-16 17:10 UTC by Martin Wilck
Modified: 2014-03-17 02:20 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-05-28 07:20:13 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2001:085 normal SHIPPED_LIVE New SysVinit package to fix hangs on serial console 2001-06-21 04:00:00 UTC

Description Martin Wilck 2001-05-16 17:10:02 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.16-22mw i686)

Description of problem:
If fsck reports an error at system bootup, "sulogin" is invoked to allow
root to repair the broken filesystem(s) manually. The sulogin in SysVinit
2.78-15 exits immediately without giving the opportunity to enter the root
password, causing an immediate reboot. No filesystem repair can be done.

Suggested patch below. 

How reproducible:

Steps to Reproduce:
1. start sulogin in a terminal without arguments: "sulogin".
2. Alternatively (not recommended): delibarately corrupt a filesystem such
that fsck can't repair it automatically, then boot.

Actual Results:  Program prints it startup message, but exits immediately.
Expected Results:  Should have waited for valid root password or CTRL-D.

Additional info:
The problem occurs only if sulogin is called without arguments (on the
current terminal).

The bug was introduced with a recent patch (sysvinit-2.78-notty.patch)
in the SRPM that solved a security issue.

The following small patch solves the problem:

--- sysvinit-2.78/src/sulogin.c.old	Wed May 16 18:18:04 2001
+++ sysvinit-2.78/src/sulogin.c	Wed May 16 18:56:18 2001
@@ -335,7 +335,7 @@
 	char *tty = NULL;
 	char *p;
 	struct passwd *pwd;
-	int c, fd;
+	int c, fd = -1;
 	pid_t pid, pgrp, ppgrp, ttypgrp;
@@ -402,7 +402,7 @@
 		} else
 	} else {
-		if (fd>=0) close(fd);
+		if (tty && fd>=0) close(fd);

Comment 1 Bill Nottingham 2001-05-17 19:47:28 UTC
I can't reproduce this here. sulogin behaves correctly when I run it from the
command line.

Comment 2 Martin Wilck 2001-05-18 07:08:11 UTC
Probably that's a question of what the random initial value of "fd" is.
(fd is a local variable which is consequently not initalized).

On my systems, the value was 0 (both IA32 and IA64).
Thus, if tty==0, fd stays 0 in line 369, and file descriptor 0 is closed on line
The read statement in getpasswd returns -1 (invalid file descriptor), and
mistakes that for a CTRL-d input (it checks only if the return value is <= 0).

If fd has another value (which I suspect is the case on your system), the close 
statement on line 405 will return an error condition which is not checked
and file descriptor 0 will stay open, leading to correct behaviour in the

My patch fixes this random behaviour. Actually the change in line 338 is only to
get rid of
the "fd might be used uninitialized in this function" warning, which actually
gets to the point
of this problem.

Comment 3 Bill Nottingham 2001-05-25 15:40:47 UTC
Yes, I see. As you said, the first part is really cosmetic. How
are you getting sulogin run without a tty?

Comment 4 Martin Wilck 2001-05-28 07:20:08 UTC
I'm not sure if I understand your question right, but "tty" is initialized to
NULL in 
line 335 and only gets a different value (line 368) if "sulogin" is called with
tty command line argument (e.g. "sulogin /dev/tty10").

rc.sysinit on RedHat systems simply calls "sulogin" (rightly so), thus tty will
be NULL.

Comment 5 Bill Nottingham 2001-06-12 16:21:35 UTC
I'm still curious as to how it works here (it appears to work fine in all tests
I throw at it.)

In any case, these changes are in SysVinit-2.78-16.

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