Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site decvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!marc
From: marc@decvax.UUCP (Marc Teitelbaum)
Newsgroups: net.unix,net.unix-wizards,net.bugs.uucp
Subject: multiple uucp logins sharing uids and hard links to ttys
Message-ID: <248@decvax.UUCP>
Date: Thu, 7-Aug-86 15:21:50 EDT
Article-I.D.: decvax.248
Posted: Thu Aug  7 15:21:50 1986
Date-Received: Sat, 9-Aug-86 08:49:47 EDT
Reply-To: marc@decvax.UUCP (Marc Teitelbaum)
Organization: DEC Ultrix Engineering Group, Merrimack, NH
Lines: 88
Xref: watmath net.unix:8832 net.unix-wizards:19100 net.bugs.uucp:775

I've seen a lot on the net recently about both uucp login uids and
links to tty devices.  Some correct observations, and some incorrect.
Anyway, heres what i know about this topic.  If you think i've missed
something please send me mail first before posting to everyone.

First we need to understand how uucp verifies login identity, and by doing 
so, file access and execution privilege for the remote system as set forth 
in the USERFILE.

UUCP LOGIN VERIFICATION - or - who called us

	The algorithm is:

	A) try and see what login name logged in on the controlling terminal.
	B) if that fails, get the uid (getuid()) and look
	   it up in /etc/passwd.  Note: if /etc/password contains
	   multiple login names all sharing the same uid, just
	   the first one is used.

	This is the standard mechanism a program should use for
	determining the login identity.  Test A 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.

	Uucp (or properly, uucico) does not detach from the controlling
	terminal.  That is, test A should not fail.  Note further, test
	A will return the proper login name even if it shares uids with
	other login names.
	
HOW TEST "A" CAN FAIL
	
	Test A is performed by the getlogin() library routine.  To make
	a small story short, eventually getlogin calls a routine which
	compares the inode number of the "controlling terminal" (actually
	it just checks fd's 0, 1, or 2) with the inode numbers of the
	terminals in /dev.  The first one which matches wins and is returned
	as the name of the tty this process logged in on.  Then this name
	is searched for in /etc/utmp.

	Heres the problem:  If there is a hard link between two tty entries, 
	say ttyd1 and tty01, and ttyd1 appears first in the directory, then
	ttyd1 will be returned as the tty the process logged in on (since
	links all point to one inode).  Now, if tty01 appears in /etc/ttys
	instead of ttyd1, then tty01 will be in /etc/utmp.  The routine
	can never make the match.

	If test A fails, then test B will return the name of whoever
	happens to appear first in /etc/passwd with that uid.  If this
	happens to be "uucp" itself (not unlikely) - and uucp does not 
	appear in your USERFILE, then either the call will fail - or worse, 
	will succeed with the wrong file access and execute permissions.

THE SOLUTION

	DO NOT MAKE HARD LINKS IN /DEV - AT ALL.  Attempts to rearrange
	the position of the directory entry are subject to specifics
	of the implementation.  It may work now, but maybe not with
	release X.XX.  Do not sigh, there is another way:

	If you must have different names for the same tty device then
	use mknod to create a new device file with the same major minor
	pair.  The will give you a file with a unique inode number
	which points to the same device.  By doing "ls -li /dev/tty*"
	you can identify links to tty files.  Look both at the link
	count, and the inode number to identify those tty files which
	are links to each other.  For each set of links, jot down the
	major minor numbers and rm -f all but one of them.  Then use
	mknod to create new files.  If you have ULTRIX you will see
	that i put this in the release notes.  For the last release of
	ULTRIX i eliminated any use of hard links in /dev.  I recommend
	anyone having this problem do the same.

THE CONFUSION

	As in any subtle bug, it is a variety of factors which
	contribute to the problem.  The conditions are: same uids for
	uucp login names, hard links to tty devices (which the modems
	are connected to), and the link not present in /etc/ttys
	appears first in the /dev/ directory.  The real culprit is the
	hard links.  Remove them and you will cure the problem.  So to
	clear up any confusion: there is nothing wrong with having uucp
	logins all share the same uid.

Marc Teitelbaum		uucp: decvax!marc	ENET: gorge::marc