On Mon, Jan 02, 2017 at 02:06:01PM -0500, Chet Ramey wrote:
> On 1/2/17 6:09 AM, Russell King wrote:
> > On Sun, Jan 01, 2017 at 09:14:45PM -0500, Chet Ramey wrote:
> >> On 1/1/17 4:01 PM, r...@armlinux.org.uk wrote:
> >>> Bash Version: 4.3
> >>> Patch Level: 30
> >>> Release Status: release
> >>>
> >>> Description:
> >>> Running:
> >>> while :; do s=$(sleep .005 | cat); echo $s; done | uniq
> >>> in a login shell on a virtual terminal or serial console results
> >>> in the shell randomly logging out after ^C.
> >>
> >> I believe this is fixed in bash-4.4.
> >
> > Thank you for your reply.
> >
> > However, while testing bash-4.4 with the five additional patches (bringing
> > it to 4.4.5) shows that it is not fixed in bash-4.4 - see below. The line
> > from __tty_check_change() is from the debug I added to the kernel, which
> > shows that the reason for the EIO error is because the tty pgrp doesn't
> > match the process' pgrp.
>
> OK. I can't reproduce it on Fedora 25.
Digging into why Fedora doesn't show it comes down to distro choices.
Fedora ships util-linux login, which does this when starting the shell:
setsid() = 14301
open("/dev/pts/4", O_RDWR|O_NONBLOCK|O_LARGEFILE) = 3
ioctl(3, TCGETS, {B38400 opost isig icanon echo ...}) = 0
fcntl64(3, F_GETFL) = 0x8802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE)
fcntl64(3, F_SETFL, O_RDWR|O_LARGEFILE) = 0
close(0) = 0
close(1) = 0
close(2) = 0
dup2(3, 0) = 0
dup2(3, 1) = 1
dup2(3, 2) = 2
close(3) = 0
ioctl(0, TIOCSCTTY, 1) = 0
rt_sigaction(SIGINT, {SIG_DFL, [INT], SA_RESTART}, {SIG_IGN, [], 0}, 8) = 0
setuid32(0) = 0
chdir("/root") = 0
execve("/home/rmk/bash/bash-4.4/build-pristine/bash", ["-bash"], [/* 8 vars
*/]) = 0
This has the effect that bash sees that the existing PGRP is the same
as the PID - so bash's "original_pgrp" and "shell_pgrp" end up as the
same thing.
Debian and Ubuntu ship shadow-utils login, which makes no calls to
setsid, no TIOC*PGRP calls, no TIOCSCTTY calls. It also makes no
attempt to open the tty itself, using the stdin/stderr supplied
to print it's prompts and read the login name and password.
This results in bash's "original_pgrp" being the PID of the login
process, and "shell_pgrp" the PID of the top level bash - and that
is a requirement for triggering the bug.
So, systems using util-linux login will not show this bug. Systems
using shadow-utils login do show the bug.
Now also reproduced it on a single-CPU machine, also using the
shadow-utils login.
--
Russell King
