SIGTTIN when exec-ing from .profile/.bashrc

[neil . hoggarth]

Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' 
-DCONF_VENDOR='redhat' -DSHELL -DHAVE_CONFIG_H  -D_FILE_OFFSET_BITS=64  -I.  
-I. -I./lib -I/usr/include -g -O2
uname output: Linux pc-linus.physiol.ox.ac.uk 2.2.16-3 #1 Mon Jun 19 18:10:14 
EDT 2000 i486 unknown
Machine Type: i386-redhat-linux-gnu

Bash Version: 2.03
Patch Level: 8
Release Status: release

Description:

If bash2 is started as a login shell from /bin/login, and .profile or
.bashrc use the exec builtin to replace the shell with another process
then the newly exec-ed process appears to have problems reading from
the terminal - strace shows such a process stuck in a tight loop,
repeatedly processing SIGTTIN.

This affects /bin/bash2 in the Redhat 6.x GNU/Linux distribution, as
well as /bin/sh and /bin/bash on RedHat 7.0 (which are both bash v2).

The problem doesn't manifest itself if bash v1 is used as a login
shell on the same system. It only appears to occur when bash2 is
exec-ed from /bin/login - such as when the login occurs over telnet or
on the console. It doesn't occur when bash2 is the login shell but has
been launched by sshd rather than login.

Repeat-By:

Create a .profile which contains something like "exec tcsh". Make
bash2 the login shell for the account. Attempt to login.