Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!rochester!cornell!uw-beaver!mit-eddie!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Pseudo-tty ownership problem
Message-ID: <6503@brl-smoke.ARPA>
Date: Fri, 2-Oct-87 17:20:31 EDT
Article-I.D.: brl-smok.6503
Posted: Fri Oct  2 17:20:31 1987
Date-Received: Sat, 3-Oct-87 10:17:39 EDT
References: <730@quacky.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Distribution: world
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 33

In article <730@quacky.UUCP> dce@mips.UUCP (David Elliott) writes:
>1. Change the commands that work with ptys to be setuid root.
	Extremely insecure!  Large set-UID programs nearly always
	have security holes.
>2. Change the commands to call a setuid root command that will
>   change the ownership of the given tty.
	This is workable (see the DMD "relogin" utility), but
	it doesn't solve the entire problem, which also includes
	locating a pty (or group of ptys), chown'ing and chmod'ing
	the pty, and putting it back the way it was when done.
>3. Change mesg and biff to be setuid root and add code to them
>   to figure out if the operation should be allowed ...
	NO NO NO!  It is essential that "mesg", "talk", "write", etc.
	NOT write on ptys that have not authorized such "break-
	through" writes.  Quite often I'm conducting a specialized 
	protocol between host software and downloaded interface code
	and cannot tolerate unexpected garbage being sent down that
	channel.  /etc/utmp, if it is to have any use at all, is
	the proper place to find out the terminal to be used for
	such communications.
>4. Change the pty driver in the kernel such that it sets the owner
>   of a pty slave to the userid of the owner the first time the
>   pty is opened for writing.
	Yuck!  It doesn't solve the entire problem.
>Any help or additional ideas are welcome.
	A pty manager daemon, which hands out ptys upon request
	(setting their owner and modes) would be useful.  It can
	also update /etc/utmp upon request.  The latter function
	could be delegated to a "relogin" utility, which is useful
	in its own right (e.g. when a user wants to change which of
	his layers is to be the "communication layer").
	The hard part is making sure the pty is properly reset
	(owner, mode) when the application is through with it.