jbayer@ispi.UUCP (Jonathan Bayer) (03/07/89)
I have experienced a problem with HDB UUCP as it is distributed with SCO Xenix. The relevent information follows: Permission file entry: MACHINE=libcmp LOGNAME=libcmp \ COMMANDS=uucp:rmail \ READ=/usr/spool/uucppublic:/usr/tmp \ WRITE=/usr/spool/uucppublic:/usr/tmp \ SENDFILES=yes REQUEST=yes System file entry: libcmp Never ACU 19200 p0000 ogin:--ogin:--ogin: nuucp File permissions: drwxr-xr-x 34 backup bin 576 Feb 17 13:12 /usr/ drwxrwxrwx 12 backup bin 192 Dec 13 14:51 /usr/spool/ drwxrwxrwx 6 uucp uucp 112 Mar 6 14:05 /usr/spool/uucppublic/ drwxrwxrwx 2 root root 48 Mar 6 14:07 /usr/spool/uucppublic/rn/ -rw-rw-rw- 1 root root 29205 Mar 6 14:07 /usr/spool/uucppublic/rn/part01.Z Log file result (I broke the line up and inserted the backslashes) uucp libcmp (3/6-11:42:58,3290,0) REMOTE REQUESTED \ (ispi!/usr/spool/uucppublic/rn/part01.Z --> \ libcmp!/usr/spool/uucppublic/rn/part01.Z (root)) root libcmp (3/6-11:42:58,3290,0) REQUESTING (DENIED) As you can see, the remote system was able to call up and successfully log into my system. However, it was not able to access any file which it should have been able to. I was able to successfully transfer the information by uucp'ing the information, and then having them call up. Any ideas? Please e-mail, if there is enough interest I will post a summary. Thanks in advance. JB -- Jonathan Bayer Beware: The light at the end of the Intelligent Software Products, Inc. tunnel may be an oncoming dragon 19 Virginia Ave. ...uunet!ispi!jbayer Rockville Centre, NY 11570 (516) 766-2867 jbayer@ispi.UUCP
keith@g4lzv.co.uk (Keith Brazington) (03/13/89)
In article <483@ispi.UUCP>, jbayer@ispi.UUCP (Jonathan Bayer) writes: > Permission file entry: > > MACHINE=libcmp LOGNAME=libcmp \ > COMMANDS=uucp:rmail \ > READ=/usr/spool/uucppublic:/usr/tmp \ > WRITE=/usr/spool/uucppublic:/usr/tmp \ > SENDFILES=yes REQUEST=yes > > System file entry: > > libcmp Never ACU 19200 p0000 ogin:--ogin:--ogin: nuucp The problem with this is the LOGNAME entry. It should be LOGNAME=nuucp assuming that the remote uses this as the login id to get into the system. Remember that MACHINE is the ID of the machine, and that LOGNAME is the ID used to gain access to uucico. Keith Brazington -- UUCP ..!ukc!pyrltd!slxsys!g4lzv!keith | Keith Brazington Smart mail keith@g4lzv.co.uk | 5b Northgate Rochester Kent UK Ampanet [44.131.8.1] and [44.131.8.3] | +44 634 811594 Voice Packet G4LZV @ GB7SEK -- G4LZV USENET BB --| +44 634 401210 Data v22,v22bis
jbayer@ispi.UUCP (Jonathan Bayer) (03/15/89)
In article <609@g4lzv.co.uk> keith@g4lzv.co.uk (Keith Brazington) writes: >In article <483@ispi.UUCP>, jbayer@ispi.UUCP (Jonathan Bayer) writes: }} Permission file entry: }} }} MACHINE=libcmp LOGNAME=libcmp \ }} COMMANDS=uucp:rmail \ }} READ=/usr/spool/uucppublic:/usr/tmp \ }} WRITE=/usr/spool/uucppublic:/usr/tmp \ }} SENDFILES=yes REQUEST=yes }} }} System file entry: }} }} libcmp Never ACU 19200 p0000 ogin:--ogin:--ogin: nuucp } }The problem with this is the LOGNAME entry. It should be LOGNAME=nuucp }assuming that the remote uses this as the login id to get into the system. }Remember that MACHINE is the ID of the machine, and that LOGNAME is the ID used }to gain access to uucico. } }Keith Brazington That is not the problem since I had set up a special login id for use by libcmp. Amazingly enough, the login id was "libcmp" JB -- Jonathan Bayer Beware: The light at the end of the Intelligent Software Products, Inc. tunnel may be an oncoming dragon 19 Virginia Ave. ...uunet!ispi!jbayer Rockville Centre, NY 11570 (516) 766-2867 jbayer@ispi.UUCP
jack@turnkey.TCC.COM (Jack F. Vogel) (03/17/89)
In article <609@g4lzv.co.uk> keith@g4lzv.co.uk (Keith Brazington) writes: >In article <483@ispi.UUCP>, jbayer@ispi.UUCP (Jonathan Bayer) writes: >> Permission file entry: >> >> MACHINE=libcmp LOGNAME=libcmp \ >> COMMANDS=uucp:rmail \ >> READ=/usr/spool/uucppublic:/usr/tmp \ >> WRITE=/usr/spool/uucppublic:/usr/tmp \ >> SENDFILES=yes REQUEST=yes >> >> System file entry: >> >> libcmp Never ACU 19200 p0000 ogin:--ogin:--ogin: nuucp > >The problem with this is the LOGNAME entry. It should be LOGNAME=nuucp >assuming that the remote uses this as the login id to get into the system. >Remember that MACHINE is the ID of the machine, and that LOGNAME is the ID used >to gain access to uucico. This is not true, I do not remember exactly what the problem of the original poster was but LOGNAME does not need to be equal to nuucp. I have a number of sites that login as nuucp but their LOGNAME is equal to their real systemid. "nuucp" is the id passed through getty to login and identifies the 'shell' to run as uucico, LOGNAME is determined during the uucp handshaking between the two systems after uucico is started up, when it gets that id it looks in the Permissions file for a LOGNAME equal to that id. Also it is not true that MACHINE is the id of the incoming system, rather it is the id used when your system makes an outbound call, at that time uucico again checks Permissions, this time for the MACHINE id rather than for LOGNAME. I realize this does not resolve whatever the original problem was, but then incorrect information helps even less. -- Jack F. Vogel Turnkey Computer Consultants, Westchester,CA UUCP: ...{nosc|uunet|gryphon}!turnkey!jack Internet: jack@turnkey.TCC.COM or lcc!jackv@cs.ucla.edu
news@brian386.UUCP (Wm. Brian McCane) (03/22/89)
In article <6336@turnkey.TCC.COM> jack@turnkey.TCC.COM writes: =>In article <609@g4lzv.co.uk> keith@g4lzv.co.uk (Keith Brazington) writes: =>>In article <483@ispi.UUCP>, jbayer@ispi.UUCP (Jonathan Bayer) writes: =>>> Permission file entry: =>>> =>>> MACHINE=libcmp LOGNAME=libcmp \ =>>> COMMANDS=uucp:rmail \ =>>> READ=/usr/spool/uucppublic:/usr/tmp \ =>>> WRITE=/usr/spool/uucppublic:/usr/tmp \ =>>> SENDFILES=yes REQUEST=yes =>>> =>>> System file entry: =>>> =>>> libcmp Never ACU 19200 p0000 ogin:--ogin:--ogin: nuucp =>> =>>The problem with this is the LOGNAME entry. It should be LOGNAME=nuucp =>>assuming that the remote uses this as the login id to get into the system. =>>Remember that MACHINE is the ID of the machine, and that LOGNAME is the ID used =>>to gain access to uucico. => =>sites that login as nuucp but their LOGNAME is equal to their real systemid. =>"nuucp" is the id passed through getty to login and identifies the 'shell' to =>run as uucico, LOGNAME is determined during the uucp handshaking between the =>two systems after uucico is started up, when it gets that id it looks in the =>Permissions file for a LOGNAME equal to that id. Also it is not true that =>MACHINE is the id of the incoming system, rather it is the id used when your =>system makes an outbound call, at that time uucico again checks Permissions, =>this time for the MACHINE id rather than for LOGNAME. => I thought that MYNAME was the id used when your system makes an outbound call. And from the Permissions file on my system: # LOGNAME=list : specify the login(s) to be associated with this entry. # ( LOGNAME=nuucp ) # # MACHINE=list : specify the machine to be associated with this entry. # ( MACHINE=system5 ) ... I discovered the MYNAME command myself, by looking at the uucheck file with less. I am sure it is documented, but I dunno where. brian -- Wm. Brian McCane | Life is full of doors that won't open | when you knock, equally spaced amid Disclaimer: I don't think they even | those that open when you don't want admit I work here. | them to. - Roger Zelazny "Blood of Amber"
jack@turnkey.TCC.COM (Jack F. Vogel) (03/23/89)
In article <423@brian386.UUCP> news@brian386.UUCP (Wm. Brian McCane) writes: >=>In article <6336@turnkey.TCC.COM> jack@turnkey.TCC.COM writes: [ repetitive quoting deleted ] >=>Also it is not true that >=>MACHINE is the id of the incoming system, rather it is the id used when your ^^^^^^^^^ >=>system makes an outbound call, at that time uucico again checks Permissions, >=>this time for the MACHINE id rather than for LOGNAME. >I thought that MYNAME was the id used when your system makes an outbound >call. And from the Permissions file on my system: > ># LOGNAME=list : specify the login(s) to be associated with this entry. ># ( LOGNAME=nuucp ) ># ># MACHINE=list : specify the machine to be associated with this entry. ># ( MACHINE=system5 ) >I discovered the MYNAME command myself, by looking at the uucheck file >with less. I am sure it is documented, but I dunno where. Is it really necessary to go into boring detail in order not to be misunderstood??? Notice I said above "id used" I did not think it was required to state what it was used for. It is the id used to identify outbound permissions, NOT the name of your system. Let's say your system is called 'bozo' and you want to poll the system 'dumdum', so you issue the command: uucico -r1 -x5 -sdumdum Now uucico scans the Permissions file to check for MACHINE=dumdum and see if there are any special constraints calling dumdum, like maybe whether or not I can SENDFILES. In fact, for whatever reason you may not want to identify yourself as bozo when calling dumdum, so there will be an entry there that says MYNAME=smartguy, now you will use that id during handshaking. There, now is it all perfectly clear!?! -- Jack F. Vogel Turnkey Computer Consultants, Westchester,CA UUCP: ...{nosc|uunet|gryphon}!turnkey!jack Internet: jack@turnkey.TCC.COM || lcc!jackv@CS.UCLA.EDU
les@chinet.chi.il.us (Leslie Mikesell) (03/25/89)
In article <423@brian386.UUCP> news@brian386.UUCP (Wm. Brian McCane) writes: >=>>In article <483@ispi.UUCP>, jbayer@ispi.UUCP (Jonathan Bayer) writes: >=>>> Permission file entry: >=>>> MACHINE=libcmp LOGNAME=libcmp \ >=>>> COMMANDS=uucp:rmail \ >=>>> READ=/usr/spool/uucppublic:/usr/tmp \ >=>>> WRITE=/usr/spool/uucppublic:/usr/tmp \ >=>>> SENDFILES=yes REQUEST=yes >=>>> System file entry: >=>>> libcmp Never ACU 19200 p0000 ogin:--ogin:--ogin: nuucp >=>>Remember that MACHINE is the ID of the machine, and that LOGNAME is the ID used >=>>to gain access to uucico. MACHINE=xxx is used to locate this particular Permissions entry on an outbound call only. LOGNAME=yyy refers to the login name given to log in to the machine and is used to locate this Permissions entry also. VALIDATE=zzz in the same entry means to check that a machine claiming to be site zzz actually logged in with the login yyy (and thus had to know the password associated with login yyy if it is unique). >=>... LOGNAME is determined during the uucp handshaking between the >=>two systems Not true, LOGNAME is the login name. If you have a LOGNAME=nuucp entry in Permissions any site logging in under nuucp gets the permissions in that entry. If you need to control permission it is best to make each site use a unique login and make a LOGNAME entry for it. >I thought that MYNAME was the id used when your system makes an outbound >call. And from the Permissions file on my system: MYNAME is the site name your machine will claim to be. It can be associated with MACHINE= or LOGNAME= entries so that when you call (MACHINE) or are called (LOGNAME) you can pretend to be something other than what uname returns. >I discovered the MYNAME command myself, by looking at the uucheck file >with less. I am sure it is documented, but I dunno where. I'm sure I saw it mentioned in the 3B2 manuals but there is no mention of it in the SysVr3.2 386 manual. I hope it isn't going away because I need it for a pair of machines on a lan that pretend to be a single machine to most (but not all) of the world. Obviously they can't lie to each other... Les Mikesell
tneff@well.UUCP (Tom Neff) (03/27/89)
In article <8020@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <423@brian386.UUCP> news@brian386.UUCP (Wm. Brian McCane) writes: [talking about the Permissions file for BNU UUCP] >>I discovered the MYNAME command myself, by looking at the uucheck file >>with less. I am sure it is documented, but I dunno where. > >I'm sure I saw it mentioned in the 3B2 manuals but there is no mention >of it in the SysVr3.2 386 manual. I hope it isn't going away because >I need it for a pair of machines on a lan that pretend to be a single >machine to most (but not all) of the world. Obviously they can't >lie to each other... This almost goes without saying nowadays, but: The Nutshell handbook "Managing UUCP and Usenet" from O'Reilly & Associates covers MYNAME= as well as all the other points discussed here. Unless you are blessed with unusually good vendor documentation, you should probably have a copy of this if you want to be a UUCP site. I won't pollute the newsgroup with any further commercialism (nor am I associated with O'Reilly at all, just a satisfied customer) but you can reach them yourself at uunet!ora!nuts. -- Tom Neff tneff@well.UUCP or tneff@dasys1.UUCP
how@milhow1uunet.UU.NET (Mike Howard) (04/10/89)
SCO Xenix 2.3.1 HDB UUCP and SCO Xenix 2.2.3 UUCP use different methods to implement `uucp file machine1!machine2!directory'. If the Host machine is 2.3.1 and machine1 is 2.2.3 (or vice versa) the requested copy is denied. Example: uuto file machine1!machine2!user HDB UUCP: generates the following `uux' command: uucp -C file machine2!~/receive/user/hostmachine This fails on `XQT DENIED' if machine1 is a 2.2.3 UUCP without putting `uucp' in L.cmds. [putting uucp in L.cmds seems suicidal]. OLD UUCP: generates the request: S file machine2!~receive/user/hostmachine This fails on `PERMISSION (DENIED)' where the request is translated to: hostmachine!file --> machine1!machine2!~receive/user/hostmachine ----------------------------???????????------------------------------- Anyone else run into this? Any work around(s)? -- Mike Howard uunet!milhow1!how