Re: terminating lines with accidental eof

[Martin Wheatley]

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: Martin.Wheatley@JET.UK          |
| United Kingdom         |     or: Martin.Wheatley@UKAEA.Org.UK    |
+------------------------------------------------------------------+