tty and /dev topics (was Re: multiple uucp logins)

[Chris Torek]

In article <248 at decvax.UUCP> marc at decvax.UUCP (Marc Teitelbaum) writes:
>[getlogin] will return the true identity of the login id which
>executed the process even if the process has switched uids.  However,
>if the process has become detached (the user logged out - or some
>other means of detaching the controlling terminal was employed),
>then the best we can do is identify the current uid of the process
>and match it up in /etc/passwd.

This may be true in the latest Ultrix releases, but in fact is not
the case with a standard 4BSD kernel.  The control terminal detaching,
by what I consider an accident of implementation, leaves
fstat(detached_tty_fd, &st) returning the same old information for
the (now otherwise useless) descriptor.  vhangup() does not change
the inode to which the kernel file table entry points; rather, it
merely revokes read *and* write access to that file.

This leads to the problem some have experienced with `hangup on
last close' sometimes `failing': a background job may be holding
the terminal open.  The close that seems last is not.

I have been contemplating `fixing' vhangup to truly close the
terminal in question.  Does anyone know of any programs that would
break if ttyname() really did stop working after process detachment?

>DO NOT MAKE HARD LINKS IN /DEV - AT ALL.

At least for now, hard links to devices other than terminals are
not a problem.  Indeed, we have several such, and I am considering
creating more.  In particular, /dev/disk (*) and /dev/tape directories
sound to me rather more rational than the current 4BSD system.
But we will keep the old names, at least for a while.

----
(*) This spelling a concession to the majority of operators on the
system, and to System V. :-)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at mimsy.umd.edu