greg@uwvax.UUCP (06/09/83)
In the documentatin of getpass(3) it says that the routine reads a password from standard input if it connot open "/dev/tty." How can one make /dev/tty unopenable? Thanks for any suggestions or solutions. - Greg Johnson U. of Wisconsin - Madison
trt@rti.UUCP (06/10/83)
/dev/tty cannot be open(II)ed if, for example: 1. /dev/tty does not exist. (even /dev/null has been known to vanish when the disks are flakey.) 2. The modes on /dev/tty do not permit opening for reading. 3. There are no more available file descriptors (i.e. you have already opened > ~20 files). 4. The system has no more incore inode space. 5. A disk error occurs during the open. Awful, isn't it? Tom Truscott
msc@qubix.UUCP (06/10/83)
Opening /dev/tty will fail if the entry in u. identifying the
controlling tty has not been set.
It will also not work as expected if the entry has been set
incorrectly. I found this out when I was implementing as a tty
a video memory card and a separate serial keyboard. I
accidentally set the controlling tty to be the keyboard device
instead of the overall tty emulation device.
The result was lots of entertainment.
--
Mark
...{decvax,ucbvax}!decwrl!qubix!msc
...{ittvax,amd70}!qubix!msc
decwrl!qubix!msc@Berkeley.ARPAjlw@ariel.UUCP (06/11/83)
I am an old 'friend' of getpass(3). While we were bringing up 4.0 a few years ago we inadvertantly "rm'ed" /dev/tty (a mknod type special file). You should have seen the garbage the 'passwd' command put in /etc/passwd. Try it some time for a lark. Joseph L. Wood, III ABI Holmdel (201) 834-3759 ariel!jlw
pdl@root44.UUCP (06/12/83)
I don't understand. Why should one want /dev/tty to be unopenable? The whole point of getpass is to read a password from the terminal, so that peaople can't do tricks with it (e.g. piping millions of passwords in to see which one's right). If, on the other hand, you meant `how can /dev/tty ever not be readable?' the answer is because of `administrative error'.
mark.umcp-cs%udel-relay@sri-unix.UUCP (06/13/83)
From: Mark Weiser <mark.umcp-cs@udel-relay> In the documentatin of getpass(3) it says that the routine reads a password from standard input if it connot open "/dev/tty." How can one make /dev/tty unopenable? Thanks for any suggestions or solutions. An easy way to make /dev/tty unopenable is for someone to open it exclusive mode. This works for everyone but the superuser, who can always open everything (at least in 4.1bsd). I haven't found any way around the superuser exception. +
dbj.rice%rand-relay@sri-unix.UUCP (06/13/83)
From: Dave Johnson <dbj.rice@rand-relay>
An easy way to make /dev/tty unopenable is for someone to open
it exclusive mode.
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. The source for
the ioctl routine for /dev/tty from sys.c clears this question up exactly
(as looking at the source for the kernel does for so many other questions,
too; why do we have to read the kernel source rather than just putting it
all in the manual?). This routine is called for an ioctl on /dev/tty and
just calls the ioctl routine for your control terminal, giving it the device
id for your control terminal rather than the one for /dev/tty itself. This
routine then translates the device id to the address of the struct tty for
that terminal and sets the exclusive use bit there.
/*ARGSUSED*/
syioctl(dev, cmd, addr, flag)
caddr_t addr;
{
if (u.u_procp->p_flag&SDETACH) {
u.u_error = ENXIO;
return;
}
(*cdevsw[major(u.u_ttyd)].d_ioctl)(u.u_ttyd, cmd, addr, flag);
}
Dave Johnson
Dept. of Math Science
Rice University
dbj.rice@Rand-Relayron%brl-bmd@sri-unix.UUCP (06/13/83)
From: Ron Natalie <ron@brl-bmd> It's a kludge but you could always do something like.... for(i=0; i < NFILES; i++) dup(0); before calling getpass. -Ron
mark.umcp-cs%udel-relay@sri-unix.UUCP (06/14/83)
From: Mark Weiser <mark.umcp-cs@udel-relay> From: Dave Johnson <dbj.rice@Rand-Relay> 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...