bug-bash
[Top][All Lists]
Advanced

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

Re: terminating lines with accidental eof


From: Martin Wheatley
Subject: Re: terminating lines with accidental eof
Date: Wed, 05 Jul 2006 10:34:38 +0100
User-agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.12) Gecko/20050928



Bob Proulx wrote:
Please keep your replies to the mailing list to keep everyone involved
in the discussion instead of singling out one individual.  Also the
mailing list is archived and others may search the archive to find
previous discussions.

Martin Wheatley wrote:

The following can be used to reproduce the problem...

*       Start an xterm window

*       "su" to another user in this new xterm window

*       As this new user enter "touch /tmp/somefile" but do not hit ENTER

*       kill the xterm where the "su" was entered

*       The window evaporates but /tmp/somefile now exists!


Thank you for making a small test case example.  I was able to
recreate that behavior on my system too.  I am using the Debian su
based upon the 'shadow' system in the 'login' package.


Without the "su" there isn't a problem because the shell receives a SIGHUP and doesn't run the command. However, with the "su" the SIGHUP cannot be delivered to the shell with the partial command so it gets EOF
and proceeds to execute what is in its buffer


This really seems like a bug in the su program.  When it receives a
SIGHUP it should pass it on.  Assuming that it is getting a SIGHUP.  I
did not look into the su and signal interaction.

The 'su' command is irrelevant really, it is only a vehicle for demonstrating 
the problem with bash.
Bash may get an I/O for any number of reasons.

In reality the xterm may die for any number of reasons (workstation panic, Xserver reset, ...)

We don't think it is right that any buffered user input should be actioned until the user explicitly requests
the action (via the ENTER key).


A small point.  You are aware that the tty driver converts enter from
the keyboard into a newline?  See the tty driver 'icrnl' flag setting.
Programs never read a carriage return.  Programs actually read a
newline character.

This would, of course, break legacy programs which do not terminate
their input with a newline.


The concept of entering commands with a # at the start is well known to computing staff but to educate all users (bothe technical and non-technical) around the world of this issue is not realistic.


It is a behavior gained by experience.  Experience has sometimes been
desribed as being the toothmarks left behind after being bitten.  I
suggested it because it is what I normally do when I am concerned
about that a command may be accidentally executed before I am ready to
execute it.

It is not just commands that are, in themselves dangerous, that have to be 
considered, it is ALL commands
since any partial command is going to do something different to what the user 
intends. It follows, therefore,
that every command has to be commented until fully formed and, further, that 
command history browsing must,
similarly, present "commented" commands in case thay are executed as a result 
of this issue.

Clearly this is not a realistic solution.
A realistic solution is for interactive bash NOT to execute a command until the 
user actions it (ie
when bash executes a read() system call if the return code is <=0 then bash 
should shutdown).



This is not a hypothetical situation - a user had "su'ed" and pre-typed a command and was waiting for permission to executed the command when the xterm window was accidentally killed by another user and the buffered input was executed - resulting in unscheduled (and costly) shutdown of some
of our plant equipment.


Thank you for providing that real world example.


Surely the argument should not be as to whether the situation can or cannot happen (for whatever reason) - it clearly can (as we have experienced) and
the code should be fixed to prevent this happening at all.


Until you provided the example and the report of an actual occurrence
there was no reason to believe this had ever happened.

It is a continuing challenge to keep the system design functioning in
good ways.  It is a judgement call in most cases.

I believe it was Andrew Koenig who proposed this thought problem.
Have you ever cut yourself on a kitchen knife?  Most of us have at oneype
time or another.  Can you design a knife so that it is now impossible
to injure yourself with it?  How effective will this new design be in
the kitchen?  Would you use such a knife yourself?

I feel for you in the situation that you described.  But I also feel
that the user you mentioned pulled out a kitchen knife to cut some
vegetables.  They were holding it in their hand prepared and waiting
to start chopping when someone accidentally bumped into them from
behind when they were not looking.  Because of this they cut something
they did not want to cut with the knife they were holding.

Actually I was only thinking about getting the knife out of the drawer - but it 
cut me anyway!


There is only so much that can be done to make the world a safe place.
I personally do not see any way to improve bash in this area.  And in
addition to bash there are many other shells such as sh, ksh, zsh,
csh, tcsh, ash, etc.  You would need to change the behavior of all of
them.

Bob

--

+------------------------------------------------------------------+
| Martin Wheatley        | Voice : +44-(0)1235 464784              |
| CODAS                  | Mobile: +44-(0)468  894818              |
| UKAEA, Culham Division | FAX   : +44-(0)1235 464404              |
| Culham Science Centre  |                                         |
| Abingdon, Oxfordshire  |                                         |
| OX14 3DB               | E-mail: address@hidden          |
| United Kingdom         |     or: address@hidden    |
+------------------------------------------------------------------+




reply via email to

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