bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Failure to log in as root to serial console in bash 5.0; works in ba


From: Chet Ramey
Subject: Re: Failure to log in as root to serial console in bash 5.0; works in bash 4.4
Date: Sun, 17 Feb 2019 19:52:25 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0

On 2/16/19 10:55 AM, jpbion@jfroot.com wrote:

> Bash Version: 5.0
> Patch Level: 2
> Release Status: release
> 
> Description:
>       This all works with bash 4.4; just tested it with it, it works fine.
>       In bash 5.0, an attempt to login as root on a serial console on my
>       machine results in this failure:
> 
>           bash: initialize_job_control: no job control in background: Bad 
> file descriptor
> 
>        ...and ANY keypress results in an 'exit' being printed and the
>        connection dropped. Logging in as any other user works fine, and then
>        I can 'su' to root, and all works. Again, this works in 4.4. The code
>        that prints this (in jobs.c) seems to be new for 5.0.

This seems to be a timing problem, though I don't know why it would happen
only to root.

This code runs when the shell thinks it's started in the background: job
control is enabled, or the shell thinks it should be enabled and is trying
to initialize it, and the shell's process group (obtained using getpgid)
and the terminal's process group are not the same. The assumption is that
the shell's parent will be around to take care of this and allow the shell
to continue in the foreground.

Instead of trying to read a character, which may or may not generate
SIGTTIN, the shell just resets the handler to SIG_DFL and sends SIGTTIN
to itself.

In bash-4.4, the code to handle this just looped forever, leading to
situations like this one:

http://lists.gnu.org/archive/html/bug-bash/2016-11/msg00137.html

The change that added the warning message capped the number of times this
happened at 16 -- after 16 SIGTTINs return without changing the terminal's
process group, there probably isn't an agent there to change it, and we'll
proceed without job control and take our chances with read(2).

The shell probably exits because it either ends up in an orphaned process
group (read returns -1/EIO) or tries to read from the background process
while ignoring or blocking SIGTTIN (read returns EOF).

I suspect it's a timing issue because bash-4.4, instead of waiting forever,
eventually breaks out of that loop with shell_pgrp == terminal_pgrp,
successfully finishes initializing job control, and goes on. I don't know
how to compute the right number of loops to delay that long.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]