Locking Your terminal
Robert L. Fair
cim2 at pyuxv.UUCP
Tue Sep 10 02:30:34 AEST 1985
>
>There are only 2 problems with this approach, one minor, the other fatal.
>The minor one is that the password is kept in clear text. This can probably
>be dealt with effectively with appropriate permissions on the file (like
>0700). The fatal one is that since the shell is interpreting this file, a
>bad-guy at the terminal can generate either interrupt or quit signals faster
>than the shell can react (re-catch them). Possibly using something like
> trap '' 1 2 3 6 15
>may prevent the shell's need to react (but verify it before you use it!).
>The real answer to the security problem is to never, NEVER, *NEVER* leave
>your terminal unattended when you're logged in.
>--
> Marty Shannon
>UUCP: ihnp4!attunix!mjs
First, Thank you for a civilised response... However, the posted script
does work properly.
I ought to say that the script was only tested with the Korn
Shell, and it resisted being killed even by auto-repeating Quit signals
(Ctrl-\) from the terminal. Although it gives out masses of
"Quit - core dumped" messages (probably from the shell spawned to give
the error message), the main shell remembers that it shouldn't die
and eventually recovers to take the correct 'trap' action, and carries
on looping.
On the subject of passwords, yes I'll admit that they ought to be
encrypted, indeed I put together a script using 'makekey(1)' but
the decrease in speed make it unworkable. A 'C' program would be
nice, but defeats the object of a quick & easy solution to stop
***casual*** hackers while you briefly leave your terminal
Perhaps it was unwise to call the original posting
'Locking your terminal for Lunch' ?
Rob. Fair
Bell Communications Research,
Piscataway NJ.
pyuxv!cim2
These are my opinions, only my opinions and not the opinions of anyone,
anything, anyslug or anysnitch living or rotting.
More information about the Comp.sources.unix
mailing list