Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

TIOCSTI (was Terminals are ridiculously insecure)

12 views
Skip to first unread message

Root Boy Jim

unread,
Jan 23, 1989, 12:45:02 PM1/23/89
to
? From: Paul Eggert <egg...@sea.sm.unisys.com>

? Chris Torek writes:

? >TIOCSTI is a hack. It exists for ONE program (/usr/ucb/mail),

? Oops, I forgot about filename completion in some C shells.

I don't see why it is necessary for either. TCSH doesn't use it, and
it's completion works just as good or better.

However, as we all too soon find out, if something is available, then
if must be used, as we find out below:

? GNU Emacs, just before suspending or exiting,
? uses TIOCSTI to put back pre-read characters
? (or anything else the user wants put back).

Thanks for the info. I knew about suspending, but exiting is not documented.

STI is not a new idea. I remember various hacks to RSX-11M back when
people (other than Henry :-) used PDP-11's to do just that. I guess there
is a little group that runs around lobbying for and implementing that
feature on various operating systems.

I agree that its very existence is a security *concern*, but I can see
a few uses for it. How many times have users asked the questions: "How
can a process change the {environment,working directory} of the parent?"
This might be a good thing to do occasionally; one use would be to avoid
the cortortions of eval'ing the output of tset.

BTW, Chris, as to your idea about stuffing `foobar' in the reverse
order before typeahead input: that's the way I always thought it worked
until I looked at some code! They documented it right, they just
implemented it wrong :-)

Why doesn't TIOCSTI do a string rather than just one char?

(Root Boy) Jim Cottrell (301) 975-5688
<r...@nav.icst.nbs.gov> or <uunet!nav.icst.nbs.gov!rbj>
Crackers and Worms -- Breakfast of Champions!

Brandon S. Allbery

unread,
Jan 29, 1989, 12:27:50 PM1/29/89
to
As quoted from <18...@adm.BRL.MIL> by r...@nav.icst.nbs.gov (Root Boy Jim):
+---------------

| I agree that its very existence is a security *concern*, but I can see
| a few uses for it. How many times have users asked the questions: "How
| can a process change the {environment,working directory} of the parent?"
| This might be a good thing to do occasionally; one use would be to avoid
| the cortortions of eval'ing the output of tset.
+---------------

*gag* It's bad enough that tset has to vary its output based on my login
shell.

My idea of a (future) solution: widen the exit code to an exit environment.
This would NOT be identical to the environment that's passed in, but instead
would allow a program to provide multiple exit values. For compatibility,
exit(n) would return an exit environment containing "EXITCODE=n" and nothing
else. A program could use setxenv() to stuff other values into the exit
environment, such as "TERM=footerm". A new wait() call (waitenv()) would
take a pointer and buffer length as an argument and fill the area pointed to
with as much of the xenv as will fit. I would *not* have shells
automatically place the xenv in the environment, I would probably add a
command "import" to /bin/k?sh and "getxenv" to csh to transfer variables
into internal (NOT environment) variables and let scripts handle it from
there. (No, $foo-type ings would NOT work. $ is overloaded enough already,
especially in csh where it has to refer to either of two completely
different namespaces.)

++Brandon
--
Brandon S. Allbery, moderator of comp.sources.misc all...@ncoast.org
uunet!hal.cwru.edu!ncoast!allbery ncoast!all...@hal.cwru.edu
Send comp.sources.misc submissions to comp-sources-misc@<backbone>
NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser

David Canzi

unread,
Feb 2, 1989, 6:10:35 PM2/2/89
to
In article <13...@ncoast.ORG> all...@ncoast.UUCP (Brandon S. Allbery) writes:
>| I agree that its very existence is a security *concern*, but I can see
>| a few uses for it. How many times have users asked the questions: "How
>| can a process change the {environment,working directory} of the parent?"
>| This might be a good thing to do occasionally; one use would be to avoid
>| the cortortions of eval'ing the output of tset.
>
>*gag* It's bad enough that tset has to vary its output based on my login
>shell.
>
>My idea of a (future) solution: widen the exit code to an exit environment.
>This would NOT be identical to the environment that's passed in, but instead
>would allow a program to provide multiple exit values. For compatibility,
>exit(n) would return an exit environment containing "EXITCODE=n" and nothing
>else. ...

*gag*

Observe the following excerpt from my .login file:

set noglob
eval `tset -Q -s -e'^H' -k'^X' -m 'dialup:?vc404' -m 'gandalf:?vc404' -m 'sytek:?vc404'`

Pretty contorted, no? But most of the contortion is in the complicated
calling sequence of tset, combined with some oddities of the local
environment. For some simpler command, the following would suffice:

set noglob
eval `foo`

This isn't particularly complicated. The "eval" command and the use of
grave quotes are each individually simple features. (The "noglob"
feature seems to be a bit of a wart in the design of the csh, but I
don't know how, or if, it could have been avoided.) The only reason I
can see why these might cause problems for some people is that these
simple features are effectively lost in the 80-kilobyte feature-packed
manual "page" for csh. (Some people would rather use a tool than spend
the major part of their lives studying it. Go figure.)

Adding a new feature, exit environments, to the system and adding
support for this feature to the shell only aggravates the underlying
cause of the problem it is meant to solve.

"The chief cause of problems is solutions."

--
David Canzi Unix system design and maintenance philosophy, in a nutshell:
for( ; problem_count > 0 ; problem_count-- ) {
feature_count += 1; problem_count += 2;
}

Oliver Laumann

unread,
Feb 5, 1989, 9:14:53 AM2/5/89
to
In article <18...@adm.BRL.MIL> r...@nav.icst.nbs.gov (Root Boy Jim) writes:
> ? Oops, I forgot about filename completion in some C shells.
>
> I don't see why it is necessary for either. TCSH doesn't use it, and
> it's completion works just as good or better.

The reason why tcsh doesn't need it is that it implements its own
line editing (i.e., duplicates parts of the functionality of the
tty driver). If you implement completion by means of the secondary
break character (like the csh under 4.3 BSD does) you need TIOCSTI
to ``push back'' the result of the completion to allow the user
to edit it.

--
Oliver Laumann n...@TUB.BITNET n...@tub.UUCP

0 new messages