bug-bash
[Top][All Lists]
Advanced

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

Re: Race condition in handling SIGHUP


From: Chet Ramey
Subject: Re: Race condition in handling SIGHUP
Date: Thu, 28 Apr 2016 08:49:17 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0

On 4/27/16 6:04 AM, Siteshwar Vashisht wrote:

> While this issue was fixed by backporting somes changes (See attached
> patch) from [4]  to bash-4.2 or older versions, there is still a corner
> case which may cause race condition in handling SIGHUP in current upstream.
> 
> 'bash_tilde_expand ()' function sets 'terminate_immediately' to 1 at [5]
> 
> If SIGHUP is received and termsig_handler () gets executed before reaching
> [6], ~/.bash_history will not be updated. This can happen in a scenario
> where user is running ssh session and requests for expansion for '~', if an
> admin issues 'reboot' command at the same time then ~/.bash_history may not
> be updated.
> 
> I have 2 questions about how current upstream handles this condition :
> 
> 1. Why 'terminate_immediately' is set to 1 at [7]?

Because systems using a networked password database can hang at a priority
that doesn't interrupt the system call when a SIGHUP arrives.  The handler
gets run, but the system call gets restarted.  Setting
terminate_immediately was a way to get around that.

That's probably not as necessary as it once was, so we can try removing
that code from bash_tilde_expand.

> 2. Why 'RL_ISSTATE (RL_STATE_READCMD)' is being checked at [8]? This will
> evaluate to 0 if readline is not waiting to read a command from user. I
> believe this check can be removed.

The checks have to handle all the places terminate_immediately is being
set.  However, you need to notice how terminate_immediately can be set if
a terminating signal arrives twice before it's handled.  You don't want to
try and save the history, which involves memory allocation and multiple
system and C library calls, from a signal handler context.

That code is written the way it is to accommodate the much more common
case of users exiting a shell by hitting the `close' button on their
terminal window, which causes the terminal emulator to send one or more
SIGHUPs to the shell process, usually while readline is active.  You want
shell to try and save the history in this case, since that's what users
expect.

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



reply via email to

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