chris@umcp-cs.UUCP (Chris Torek) (08/08/86)
In article <248@decvax.UUCP> marc@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@umcp-cs ARPA: chris@mimsy.umd.edu