Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!genrad!decvax!harpo!seismo!hao!hplabs!sri-unix!mark.umcp-cs@udel-relay
From: mark.umcp-cs%udel-relay@sri-unix.UUCP
Newsgroups: net.unix-wizards
Subject: Re:  question about getpass
Message-ID: <2120@sri-arpa.UUCP>
Date: Mon, 13-Jun-83 23:10:03 EDT
Article-I.D.: sri-arpa.2120
Posted: Mon Jun 13 23:10:03 1983
Date-Received: Wed, 15-Jun-83 19:22:28 EDT
Lines: 29

From:  Mark Weiser 

	From: Dave Johnson 
	

	WRONG!  You can't open /dev/tty "exclusive mode" (I assume
	you mean the TIOCEXCL ioctl).  The device /dev/tty simply
	indirects to the specific tty that is you control terminal
	(usually the one you are logged on to) and has no struct
	tty of its own within the kernel.  If you TIOCEXCL /dev/tty,
	you really end up setting the exclusive use bit on your
	own terminal, NOT on /dev/tty itself.  This will not prevent
	some OTHER user from opening /dev/tty.  It will only prevent
	you (or some other user or process) from opening the specific
	terminal that is your control terminal...

Whoops, I didn't realize my answer would be misunderstood.  Of
course dave is right, /dev/tty is essentially a different device
for everyone who opens it.  I assumed this was understood, and
was thinking of a context in which one wished to run something
like 'su' but wanted it to read from stdin (e.g. to have a shell
script to become super-user or some other horrible thing).  In
this case you somehow want the getpasswd call in su to fail
to be able to open /dev/tty and so use stdin.

My own context was a window system I built in which stdin and
stdout had been redirected to the windows, and everything worked
great except for silly little programs like su which INSISTED
on opening /dev/tty.  But of course, that's what its there for...