🚀 go-pugleaf

> On 4BSD (and V7?) a tty must be opened for writing in order for a
> process to set the tty's modes.  This does make a certain amount of
> sense; if you don't want someone to write on your tty, then you usually
> don't want them to set your tty's mode either.

It certainly does not make sense to me.  Why would you give somebody
read permission on your tty but not write permission?
				Kenneth Almquist

The reason why stty appears confused is because stty does ioctl's
on file descriptor 1 which is standard output for your terminal.
If you try to pipe the output through more it does the ioctl's on
file descriptor 1 again, but csh redefines it to the pipe going
into more. The result being that stty is trying to find out the
terminal characteristics of the pipe rather than the terminal.
This feature is useful when you want to get or set the attributes
of another device e.g. "stty everything > /dev/ttyd0" will give
you the characteristics of ttyd0 rather than sending yours as
output to ttyd0.

Actually, you're getting the stty information for the pipe...
Stty in V7 & 4BSD did the gtty() call on fd #1 (stdout), which
is where your pipe is going. One construction which will do the
right thing is:

	(stty everything > /dev/tty) |& more

The `&' is necessary because V7/4BSD stty prints its output on stderr.

	Erik E. Fair	ucbvax!fair	fair@ucb-arpa.ARPA

	dual!fair@BERKELEY.ARPA
	{ihnp4,ucbvax,hplabs,decwrl,cbosgd,sun,nsc,apple,pyramid}!dual!fair
	Dual Systems Corporation, Berkeley, California

Your problem with 'stty everything | more' giving you confusing results
(i.e. the old driver) probably stems from the fact that stty uses the
standard output to get its information and do its work, and then prints
its results on the standard error.  Since stdout is now directed to
a pipe, it's unclear what results you should expect.

Personally, I think stty should do its work on the standard input, so that
anything it prints can be EASILY redirected (through a pipe or otherwise),
though I must say that:  stty 1200 >/dev/ttyd0  looks more meaningful than
stty 1200 </dev/ttyd0.
-- 

Kurt Haserodt				..!ihnp4!wucs!kurt
Box 1045 Washington University		(314)-889-6160
St. Louis, MO 63130   USA

In article <895@trwrb.UUCP> simpson@trwrb.UUCP (Scott Simpson) writes:
~| 
~| 	Here is an interesting anamoly of the C shell and the way it
~| forks off processes.  When you type "stty everything", you get what
~| you expect: the state of your terminal using the new tty driver.
~| When you type "stty everything | more", you get the (confused) old
~| terminal driver.

Sorry, that has nothing whatsoever to do with the way csh forks off
processes. You'll get the same reponse with sh. "stty" sends its
information to stderr, and by default looks on stdout to determine
what the settings are. When you type "stty | more", stty looks down
a pipe, finds no terminal there (and does its best) and puts the
information on the diagnostic output.

Incidentally, it's because stty looks on stdout and writes on stderr
that the way to find out the speed or other parameters of a user on
"ttyx" is the rather curious
	stty > /dev/ttyx


Dave Sherman
Toronto
-- 
 {allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsrgv!dave

The USG UNIX solution is, I think, better; the USG "stty" command acts on
its standard *input*.  That way, you can redirect its output; there is an
option to "stty" to dump the terminal modes in a binary (BCHex) form, and to
set them from that form, so shell scripts can save and restore the modes.
Of course, if you don't know about this change, you can get very confused.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy

I use Uniplus+ System III, and here "stty" looks at stdin, NOT stdout.
It prints its output on stdout.  This seems like a much more reasonable
arrangement.  There is an option (-g) which makes it output an octal
string that can be used as input for another stty.  Since it outputs on
stdout, this can be used as
	OLDMODES=`stty -g`
	stty ...
	....
	stty $OLDMODES
-- 
    Barry Margolin
    ARPA: barmar@MIT-Multics
    UUCP: ..!genrad!mit-eddie!barmar

Stty on USG 5.0 systems currently uses stdin to get/set terminal characteristics.

However, more (at least on our system) changes the terminal mode so the
stty is printing everything AFTER more has changed things to suit him.

From Guy Harris (guy@rlgvax.UUCP):

	The USG UNIX solution is, I think, better; the USG "stty"
	command acts on its standard *input*.

There is a reason for the curious behavior of the Berkeley 'stty', as
I'm sure Guy knows, and it's probably useful to mention it in passing.
On 4BSD (and V7?) a tty must be opened for writing in order for a
process to set the tty's modes.  This does make a certain amount of
sense; if you don't want someone to write on your tty, then you usually
don't want them to set your tty's mode either.  It was decided that it
was simpler to get and set modes on the same descriptor, hence the
output to stderr and so on.

I'm not sure how USG Unix handles this: does the tty merely have to be
writable, as opposed to being opened for writing?  Does 'stty' get
modes from stdin and set them on stdout?  Does it care how the
descriptor was obtained?  The second of these alternatives (get stdin,
set stdout) would work on 4BSD...  If there was a '-c' option for
copying modes, you could perhaps say 'stty -c < /dev/ttyz1 >
/dev/ttyz2' and copy the modes from one tty to another.  'stty -g'
sounds useful, except that the output of 'stty' is already so close to
being input to 'stty' that it's a pity (ouch) it wasn't extended a
little farther so that 'stty < /dev/ttyz1 > file; stty `cat file` >
/dev/ttyz2' could work.

More wishful thinking,

Donn Seeley    University of Utah CS Dept    donn@utah-cs.arpa
40 46' 6"N 111 50' 34"W    (801) 581-5668    decvax!utah-cs!donn

Relay-Version: version B 2.10 5/3/83 based; site houxm.UUCP
Posting-Version: version B 2.10.1 6/24/83; site brl-tgr.ARPA
Message-ID: <3954@brl-tgr.ARPA>
Date: Tue, 14-Aug-84 12:24:30 EDT
Date-Received: Mon, 20-Aug-84 15:28:50 EDT

tty' uses stdout instead of stdin
Organization: Ballistics Research Lab
Lines: 8

So long as ioctl requires a file descriptor, the normal access
permissions on a terminal special file suffice for protection.
At BRL, general terminals do not have write permission enabled;
rather, the execute bit indicates whether a "write" or "talk"
connection is permitted, and the utilities dealing with this
have all been changed to understand the convention.  This pretty
much solves the problem of obnoxious users messing around with
your terminal from elsewhere.

[The world is a Klein bottle]

> From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>)

> At BRL, general terminals do not have write permission enabled;
> rather, the execute bit indicates whether a "write" or "talk"
> connection is permitted, and the utilities dealing with this
> have all been changed to understand the convention.  This pretty
> much solves the problem of obnoxious users messing around with
> your terminal from elsewhere.

I have two questions about this:

(1) Why the heck is ioctl not protected?  I would think that "owner or root"
would be a darned good idea; is there something complex about this that pre-
vents protecting the ioctl() system call?

(2) This suggestion would be enhanced by (1) above, but is workable anyway;
if you can tell that you are doing an ioctl get, why not GET from fd 0 and
SET from fd 1?  This would be MUCH easier on everyone; and makes for a logical
shell syntax:

(this is v7 stty I show)

$ stty -l </dev/tty1 ; : this reads ioctl info from tty1
...
$ stty cbreak >/dev/tty1 ; : this is likely to get the guy on tty1 upset...

I can't see any problems with this way of doing it; am I missing something?

--bsa
-- 
  Brandon Allbery: decvax!cwruecmp{!atvax}!ncoast!bsa: R0176@CSUOHIO.BITNET
   					       ^ Note name change!
	 6504 Chestnut Road, Independence, OH 44131 <> (216) 524-1416

"The more they overthink the plumbin', the easier 'tis tae stop up the drain."

Relay-Version: version B 2.10 5/3/83 based; site houxm.UUCP
Posting-Version: version B 2.10.1 6/24/83; site brl-tgr.ARPA
Message-ID: <4139@brl-tgr.ARPA>
Date: Tue, 21-Aug-84 11:49:54 EDT
Date-Received: Tue, 28-Aug-84 06:15:09 EDT

tty' uses stdout instead of stdin
Organization: Ballistics Research Lab
Lines: 16

Ioctl() is not the only problem; consider
	cat /unix >/dev/tty01
where some fool has left his terminal (/dev/tty01) writable to the world.
Worse yet, send him a character sequence like
HOME CR LF cd; find . -exec chmod 777 {} \; &
CLEAR_TO_END_OF_SCREEN HOME DUMP_SCREEN CLEAR 
(using the appropriate codes for his terminal type) and you will get him
to chmod all his files so you can play with them.  Short of refusing to
purchase terminals with a DUMP_SCREEN feature (or programmable function
keys that can be both programmed and played back under computer control),
the only way to avoid this security bug (which could be REALLY bad if the
victim is super-user at the time) is to prevent writes on terminals by
other users except via trusted system code.

When a user is not logged in, the terminal can be writable.  This is
handy for daisy-wheel printers, for example.

> Ioctl() is not the only problem; consider
> 	cat /unix >/dev/tty01
> where some fool has left his terminal (/dev/tty01) writable to the world.
> Worse yet, send him a character sequence like
> HOME CR LF cd; find . -exec chmod 777 {} \; &
> CLEAR_TO_END_OF_SCREEN HOME DUMP_SCREEN CLEAR 
> (using the appropriate codes for his terminal type) and you will get him
> to chmod all his files so you can play with them.  

If the above can work if 'write'ing or 'cat'ing to a /dev/tty*,
wouldn't it also work if you mailed it to someone, or posted it
to net.general?  I tried mailing myself a string of control characters,
and 'mail' unquestioningly sent them to my terminal. 
I have seen manuals containing FF characters come across 'readnews'.
Do other systems filter these out, or are we all vulnerable?

I keep 'mesg y', and don't consider myself a fool.  I also don't filter
control characters out of my 'mail' or 'readnews'.  I would send you
all a control-g in this message as a test, but I could imagine people
who post propaganda to net.general putting FFs and BELs in their messages
as attention grabbers, and I think it would be a terrible precedent.  

I'll offer a free net.stonehenge subscription for whoever can bring down
every machine on the net first . . . 
-- 
 the clouds project                henry strickland
  school of ics / ga tech
   atlanta ga 30332        { akgua allegra hplabs ihnp4 }!gatech!strick

Relay-Version: version B 2.10 5/3/83 based; site houxm.UUCP
Posting-Version: version B 2.10.1 6/24/83; site brl-tgr.ARPA
Message-ID: <4432@brl-tgr.ARPA>
Date: Wed, 5-Sep-84 23:58:13 EDT
Date-Received: Thu, 13-Sep-84 12:14:47 EDT

ite', 'mail', 'readnews', et al.
Organization: Ballistics Research Lab
Lines: 2

Yup, mail containing "bad" control sequences are known as
"letter bombs" and they too can be a security problem.

It's a general problem on any terminal that has a "transmit" screen
capability.  You don't have to use Mail or News; put the control sequence in
a man page, or a README file.  Anyone who looks at it executes your
trojan horse.

A very similar serious problem arose under another operating system with
which I am familiar.  It was possible to send a message to the operator's
console that contained these control characters.  Since the console was
always privileged, it was an easy way to give your account super-user
capabilities.  After it was discovered, the operating system was changed
to filter all messages to the console and remove certain control characters.

The program that controlled your terminal was also modifed to filter these
out so you couldn't send them to another user via the equivalent of
write(1).

This experience led me to conclude that I would just as soon not use
a terminal that had "transmit screen" ability, unless I could turn it
off.

Tom Kelly  (416) 922-1937
{utzoo, ihnp4, decvax}!hcr!hcrvx1!tom