tim@cholula.UUCP (09/17/85)
I'm having trouble getting a UUCP connection to succeed with a MicroVAX
II running Ultrix 32m V1.1. Everytime I get the connection the Ultrix
machine gives me a RLOGIN message instead of a ROK message. I did get a
connection to succeed once but like a dummy I blew away the debug output.
Below is a portion of the debug output to the target system. By the way,
our system is a Pyramid 90x which is running 4.2 UUCP (basically).
uucp TheirMachine (9/9-21:22-15691) SUCCEEDED (call to TheirMachine )
imsg >\015\012\020<
Shere\000imsg >\020<
RLOGIN\000msg-RLOGIN <----- Problem Message
uucp TheirMachine (9/9-21:22-15691) HANDSHAKE FAILED (LOGIN)
Hanging up fd = 7
exit code 0
The LOGFILE on the remote machine shows a line like below...
uucp OurMachine (9/9-21:22-15691) (LOGIN VS MACHINE) FAILED
The ERRLOG shows no errors.
Now on the Ultrix machine the login for our machine is "UOurMachine" and
has an appropriate password. In the remote machine's USERFILE we also have
an entry like -- UOurMachine,OurMachine /usr/spool/uucppublic.
Does any one have any ideas on what's going here? We have had no
problems connecting to other (Non Ultrix) systems. Any help would be
appreciated.
--
-----
Tim Rosmus
...uw-beaver_____!tikal!tim Teltone Corporation
.......fluke___/ 120th Ave. N.E.
...microsoft__/ Kirkland, WA 98033
(206) 827-9626jerry@utrc-2at.UUCP (Jerry J. Deroo) (09/19/85)
> our system is a Pyramid 90x which is running 4.2 UUCP (basically). > > uucp TheirMachine (9/9-21:22-15691) SUCCEEDED (call to TheirMachine ) > imsg >\015\012\020< > Shere\000imsg >\020< > RLOGIN\000msg-RLOGIN <----- Problem Message > uucp TheirMachine (9/9-21:22-15691) HANDSHAKE FAILED (LOGIN) > Hanging up fd = 7 > exit code 0 > > The LOGFILE on the remote machine shows a line like below... > uucp OurMachine (9/9-21:22-15691) (LOGIN VS MACHINE) FAILED > The ERRLOG shows no errors. > > Now on the Ultrix machine the login for our machine is "UOurMachine" and > has an appropriate password. In the remote machine's USERFILE we also have > an entry like -- UOurMachine,OurMachine /usr/spool/uucppublic. I just ran into this situation where the USERFILE was not specified correctly on the remote machine. i is not a very descriptive errormessage. your USERFILE entry might be too specific.. try ,OurMachine /usr/....
earlw@pesnta.UUCP (20) (09/20/85)
You will get HANDSHAKE FAILED messages when you uucico to a site that
still has a LCK.YourSite file in the /usr/spool/uucp directory. The
last connection with the remote site might have failed to clear the
LCK.YourSite file and now when you call, the remote uucico thinks the
connection is already active and sends back a RLCK message or maybe a
RLOGIN. Heck, I have no idea what RLOGIN means otherwise. Which
version of uucp sends RLOGIN messages anyway?gnu@l5.uucp (John Gilmore) (09/21/85)
One reason I've seen for screwups in handshaking with a new site is if the login name that uucp calls in with is longer than some magic constant. E.g. "Udecisions" was too long, while "Udecis" worked like a champ. Note that I'm not talking about the site name, but the name that the calling uucp supplies to the login: prompt. Shouldn't matter a bit, right? Well... If any wizards knows the fix(es), please post them.
mickey@illogica.UUCP (Michael Thompson) (09/21/85)
In article <95@cholula.UUCP> tim@cholula.UUCP (Tim Rosmus) writes: > >... Everytime I get the connection the Ultrix >machine gives me a RLOGIN message instead of a ROK message. > >The LOGFILE on the remote machine shows a line like below... > uucp OurMachine (9/9-21:22-15691) (LOGIN VS MACHINE) FAILED >The ERRLOG shows no errors. > > Now on the Ultrix machine the login for our machine is "UOurMachine" and >has an appropriate password. In the remote machine's USERFILE we also have >an entry like -- UOurMachine,OurMachine /usr/spool/uucppublic. > My bet is that your login name "UOurMachine" does not have a unique UID. Some versions of UUCP (I've seen it in system V derivitives) do a getuid() call and search linearly through the password file until they find the *first* entry with a matching UID. The login name associated with that UID is what is used to check against entries in the USERFILE. On these systems, the practice of using the same UID for all UUCP accounts is not a recommended one. mickey m. (Michael Thompson) {ucbvax,decwrl}!dual!vecpyr!altos86!illogica!mickey
tim@cholula.UUCP (09/26/85)
In article <132@illogica.UUCP> mickey@illogica.UUCP (Michael Thompson) writes: => In article <95@cholula.UUCP> tim@cholula.UUCP (Tim Rosmus) writes: => > => >... Everytime I get the connection the Ultrix => >machine gives me a RLOGIN message instead of a ROK message. => > => >The LOGFILE on the remote machine shows a line like below... => > uucp OurMachine (9/9-21:22-15691) (LOGIN VS MACHINE) FAILED => >The ERRLOG shows no errors. => > => > Now on the Ultrix machine the login for our machine is "UOurMachine" and => >has an appropriate password. In the remote machine's USERFILE we also have => >an entry like -- UOurMachine,OurMachine /usr/spool/uucppublic. => > => => My bet is that your login name "UOurMachine" does not have a unique => UID. Some versions of UUCP (I've seen it in system V derivitives) do => a getuid() call and search linearly through the password file until => they find the *first* entry with a matching UID. The login name => associated with that UID is what is used to check against entries => in the USERFILE. => => mickey m. => (Michael Thompson) => {ucbvax,decwrl}!dual!vecpyr!altos86!illogica!mickey Thanks Michael for the fix to the problem. Never even crossed my mind since 4.2 systems don't care about that. Apparently Ultrix UUCP is a mixture of SYS5 and 4.[23] UUCP. -- ----- Tim Rosmus ...uw-beaver_____!tikal!tim Teltone Corporation .......fluke___/ 120th Ave. N.E. ...microsoft__/ Kirkland, WA 98033 (206) 827-9626
avolio@decuac.UUCP (Frederick M. Avolio) (09/28/85)
In article <98@cholula.UUCP>, tim@cholula.UUCP writes: > In article <132@illogica.UUCP> mickey@illogica.UUCP (Michael Thompson) writes: > => My bet is that your login name "UOurMachine" does not have a unique > => UID. Some versions of UUCP (I've seen it in system V derivitives) do > => a getuid() call and search linearly through the password file until > => they find the *first* entry with a matching UID. The login name > => associated with that UID is what is used to check against entries > => in the USERFILE. > > Thanks Michael for the fix to the problem. Never even crossed my mind since > 4.2 systems don't care about that. Apparently Ultrix UUCP is a mixture of > SYS5 and 4.[23] UUCP. I am glad a fix was found, but based on the LOGFILE entries and our experience the problem was not on the Ultrix system side. We talk to 13 or so other sites -- Ultrix systems and non-Ultrix systems -- using the Ultrix-32 UUCP. On our system as well as on some of the others, the uucp login names are different but are all the same UID for different systems. We have no problems. I suspect the problem -- based on the LOGFILE entries -- was in the USERFILE of the other system. In fact, the problem might be with a UUCP that didn't recognize system names of more than 6 characters. Fred.
mickey@illogica.UUCP (Michael Thompson) (09/30/85)
In article <636@decuac.UUCP> avolio@decuac.UUCP (Frederick M. Avolio) writes: >I article <98@cholula.UUCP>, tim@cholula.UUCP writes: >>In article <132@illogica.UUCP> mickey@illogica.UUCP (Michael Thompson)writes: >> => My bet is that your login name "UOurMachine" does not have a unique >> => UID. Some versions of UUCP (I've seen it in system V derivitives) do >> => a getuid() call and search linearly through the password file until >> => they find the *first* entry with a matching UID. The login name >> => associated with that UID is what is used to check against entries >> => in the USERFILE. >> >> Thanks Michael for the fix to the problem. Never even crossed my mind since >> 4.2 systems don't care about that. Apparently Ultrix UUCP is a mixture of >> SYS5 and 4.[23] UUCP. > >I am glad a fix was found, but based on the LOGFILE entries and our >experience the problem was not on the Ultrix system side. We talk to 13 >or so other sites -- Ultrix systems and non-Ultrix systems -- using the >Ultrix-32 UUCP. On our system as well as on some of the others, the uucp >login names are different but are all the same UID for different systems. >We have no problems. I suspect the problem -- based on the LOGFILE >entries -- was in the USERFILE of the other system. In fact, the problem >might be with a UUCP that didn't recognize system names of more than 6 >characters. > >Fred. Please keep in mind that as long as there *is* an entry in the remote USERFILE which corresponds to the first matching login name that is associated with the UID of the uucp account, then things will *appear* to work properly. But the implications of this can be illustrated thus: USERFILE: uucp, / pubuucp,somesys /usr/spool/uucppublic /etc/passwd: uucp:xCXK46Ju1PE1Q:4:4:UUCP account: ... pubuucp:rSL55Z9flVWhs:4:4:some other uucp account: ... Since both `pubuucp' and `uucp' have the same UID, the protections implied by entries in the USERFILE are *not properly enforced*. Since these certain versions of UUCP determine the login name by associating it with the first matching UID, any system logging into `pubuucp' would be givin access to / . A simple test to determine whether or not you have this type of UUCP or not is to remove, say, `pubuucp' from the remote USERFILE and see if you still have a UUCP link through that account. Or, you can remove the entry in the remote USERFILE which corresponds to `uucp' in my example. If you have this type of UUCP, all of your UUCP links which share UID's with `uucp' will fail. I don't know if this should be classified as a bug or not, but it certainly presents some security problems as well as other possible headaches - USERFILE: uucp, /usr/spool/uucppublic myuucp,mysys /usr/mickey /etc/passwd: uucp:xCXK46Ju1PE1Q:4:4:UUCP account: ... myuucp:rSL55Z9flVWhs:4:4:my own private UUCP account ... I could be banging my head against the wall trying to figure out why UUCP denies me access to my home directory even though I explicitly grant access in the USERFILE. mickey m. (Michael Thompson) {decwrl,ucbvax}!dual!vecpyr!altos86!illogica!mickey