marc@decvax.UUCP (Marc Teitelbaum) (08/07/86)
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
csg@pyramid.UUCP (Carl S. Gutekunst) (08/09/86)
In article <248@decvax.UUCP> marc@decvax.UUCP (Marc Teitelbaum) writes: >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. Thanks, Marc; I was wondering how Ultrix handles this. I don't think you missed a thing; I just wanted to add a couple of details for other systems: - To determine the user name, 4.2bsd UUCP uses a two-step process that sounds identical to Ultrix. It also verifies the UID of the login name returned by getlogin() with a call to getpwnam(), a check that should never fail. 4.2bsd uucico does *no* login verification, so linked devices and multiple names per UID will not affect it. However, uucp, uux, and uucico (in master role) *do* verify names against the USERFILE for pathname permissions. So you won't see RLOGIN, but you may see "Access to path/file denied" when you weren't expecting it. - 4.3bsd uses the following *three* step process: Call getlogin(); if getlogin returns NULL, retrieve the USER environment variable; if this is also NULL, call getpwuid(). The return values from getlogin() and getenv("USER") are verified by calling getpwnam(); this makes more sense since it's easy to put bogus values in the environment. Like 4.2bsd, 4.3bsd does not do login verification; instead it verifies the remote hostname (or nodename, for you SV people :-)) against L.sys. (This is called "NOSTRANGERS" mode, and was borrowed conceptually from HoneyDanBer.) The uucp, uux, and uucico master role checks still apply. - SVR2 (VAX Version) uucico does login verification, but uses only getpwent() to find the user name. (System V has the getlogin() call, so there's no reason why UUCP couldn't use it. But it doesn't.) It's thus unaffected by linked devices. It does mean, though, that when you have several names per UID, it checks USERFILE for the first one in /etc/passwd. - HoneyDanBer (SVR2.4 (3B version) and SVR3) finds the user name the same way that 4.2bsd does. It verifies the login against the Permissions file, and sends "RLOGIN" when the name cannot be found. It's thus the most similar to Ultrix of the UUCPs I've described here. In addition, HDB will validate the remote hostname if the /usr/lib/uucp/remote.unkown file exists and is executable ("NOSTRANGERS" mode). <csg>
grr@cbmvax.cbm.UUCP (George Robbins) (08/09/86)
In article <564@pyramid.UUCP> csg@pyramid.UUCP (Carl S. Gutekunst) writes: >In article <248@decvax.UUCP> marc@decvax.UUCP (Marc Teitelbaum) writes: >>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. > Actually, no one seems to come out and said this, but the new Ultrix processing seems to be what I would call broken, since it imposes arbritrary restrictions not previously in effect on having multiple names (links) for terminals, when in fact earlier versions of unix and ultrix led you to believe that some lines should have multiple names (cul0,cua0,ttyd0...). Fred Avolino has been doing a good job of explaing how to getting around it, over and over again, but DEC's Ultrix should make their feelings know to DEC through whatever channels are available to them. We're still trying to find time to install 1.2, soon now I hope... -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
wescott@sauron.UUCP (Mike Wescott) (08/11/86)
In article <564@pyramid.UUCP> csg@pyramid.UUCP (Carl S. Gutekunst) writes: > - HoneyDanBer (SVR2.4 (3B version) and SVR3) finds the user name the same way > that 4.2bsd does. It verifies the login against the Permissions file, and > sends "RLOGIN" when the name cannot be found. It's thus the most similar to > Ultrix of the UUCPs I've described here. In addition, HDB will validate the > remote hostname if the /usr/lib/uucp/remote.unkown file exists and is > executable ("NOSTRANGERS" mode). Additionally, the SVr3 version permits a "-u username" argument to uucico. This permits you to override the username checks. It is particularly useful when the uucico will not be attached to a terminal when invoked, i.e. for an ethernet connection. -Mike Wescott ncrcae!wescott -- -Mike Wescott ncrcae!wescott