Re: Controlling terminal race condition

[Chet Ramey]

Jeff Miller wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: sparc
> OS: solaris2.8
> Compiler: gcc
> Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc'
> -DCONF_OSTYPE='sol
> aris2.8' -DCONF_MACHTYPE='sparc-sun-solaris2.8' -DCONF_VENDOR='sun'
> -DLOCALEDIR=
> '/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H  -I. 
> -I. -I.
> /include -I./lib -I./lib/intl -I/big/homea/test/bash-3.0/lib/intl  -g -O2
> uname output: SunOS test 5.8 Generic_108528-13 sun4u spar
> c SUNW,Ultra-250
> Machine Type: sparc-sun-solaris2.8
> 
> Bash Version: 3.0
> Patch Level: 0
> Release Status: release
> 
> Description:
>    After forking and running the executed command bash sets the terminal
> controlling process id to the id of the process of the fork. In the
> following case the process created does another fork and execs off
> another bash shell for the new process. This new shell sets the process
> for the controlling terminal to itself and does a write and a read. It
> is possible on our test Solaris 8 system that the original calling bash
> shell will set the controlling process of the terminal to the pid that
> it originally forked to after the new process had been created. 

My opinion is that bash is doing the right thing to ensure that the
terminal always belongs to the correct foreground process group, but
that it's always possible to fool the shell by changing the terminal's
process group behind its back.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
                                                Live...Laugh...Love
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/