bug-bash
[Top][All Lists]
Advanced

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

Controlling terminal race condition


From: Jeff Miller
Subject: Controlling terminal race condition
Date: Mon, 27 Jun 2005 16:11:31 -0500
User-agent: Mozilla Thunderbird 0.9 (X11/20041103)

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. In this case is not the new bash process. It happens to do this after the new bash has done it's write but before it has done it's read, this new process still assumes it is still the controlling process. Since the bash has set up to hold SIGTTIN signals it gets an EIO on the read, the exepcted behavoir if it does the read on the terminal without controlling it. If the new process was ksh, which doesn't ignore SIGTTIN, it will get the SIGTTIN and be stopped. This is a race condition caused by bash changing the controlling terminal id, via the TIOCSPGRP ioctl, after a child process has changed itself to control. This can be reproduced easily on a Sun Fire v240 server running 5.8 Generic_108528-13. Repeat-By: The following program, if executed from the bash shell, will create the situtation previously described.

#include <stdio.h>
#include <sys/wait.h>

int
main(int argc, char **argv)
{
   int ret;
int status; pid_t pid;
   if ((pid = fork()) == 0);
   else if (pid == -1)
   {
       (void)fprintf(stderr, "Unable to fork\n");

       exit(1);
   }
   else
   {
       while ((ret = (int)wait(&status)) != pid && ret != -1);

       exit(WIFEXITED(status) ? WEXITSTATUS(status) : 1);
   }

   execl("/usr/bin/bash", "/usr/bin/bash", 0);

   fprintf(stderr, "problem\n");
   exit(5);
}

Fix:






reply via email to

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