multiple uucp logins sharing uids and hard links to ttys
Marc Teitelbaum
marc at decvax.UUCP
Fri Aug 8 05:21:50 AEST 1986
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
More information about the Comp.unix.wizards
mailing list