pjh@mccc.uucp (Pete Holsberg) (10/23/90)
I'd like to have nuucp with no passwd for anonymous uucp possibilities but my SV/386 R3.2.2 insists on asking nuucp to choose a password! How can I convince UNIX that nuucp doesn't need a password? Thanks, Pete -- Prof. Peter J. Holsberg Mercer County Community College Voice: 609-586-4800 Engineering Technology, Computers and Math UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690 Internet: pjh@mccc.edu Trenton Computer Festival -- 4/20-21/91
woods@eci386.uucp (Greg A. Woods) (10/25/90)
In article <1990Oct22.211639.14436@mccc.uucp> pjh@mccc.uucp (Pete Holsberg) writes: > I'd like to have nuucp with no passwd for anonymous uucp possibilities > but my SV/386 R3.2.2 insists on asking nuucp to choose a password! How > can I convince UNIX that nuucp doesn't need a password? Don't use sysadm (or face) to install new users, especially system type accounts. Actually that's a little one-sided, but I never trust these fancy system admin. type things! :-) Login as root, make sure no-one else is using the system (at least make sure they don't run passwd, or chsh, etc.), and edit /etc/passwd. Add a new line for nuucp, with a home directory of /usr/spool/uucppublic and a shell of /usr/lib/uucp/uucico. Make the password field blank, and choose a unique user-id, and unique group-id (if you don't already have a uulogins (or something similar) group. Don't use the same user-id or group as uucp. Eg: from /etc/passwd: nuucp::20:20:Anonymous UUCP:/usr/spool/uucppublic:/usr/lib/uucp/uucico and from /etc/group: uulogins:x:20:root,adm,sysadm,uucp If you are using shadow passwords, put an 'x' in the password field. There is a command that will update the /etc/shadow file with the new account. If you already have an nuucp account, and assuming you aren't using shadow passwords (I'm not sure what the default is anymore), all you have to do is edit /etc/passwd, and clean out the password field for nuucp. If you are using shadow passwords, I think you can do the same thing, but to /etc/shadow. Now, even if you have an nuucp account without a password, it still won't work! HDB-UUCP doesn't, by default, support anon. uucp. Each system must have a line in /usr/lib/uucp/Systems. This is a generic feature of HDB-UUCP. If you've already tried this, you'll notice in mail to the user uucp, and in the file /usr/spool/uucp/.Admin/Foreign that any attempts to initiate anonymous uucp will be recorded and reported. To change this behavior, all you need to do is remove execute permission from the script/programme /usr/lib/uucp/remote.unknown. This is all documented in the System Administrator's Guide. (Actually, a common convention is to set the nuucp password to "guest"). -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP +1-416-443-1734 [h] +1-416-595-5425 [w] VE3-TCP Toronto, Ontario CANADA
darcy@druid.uucp (D'Arcy J.M. Cain) (10/25/90)
In article <1990Oct22.211639.14436@mccc.uucp> pjh@mccc.uucp (Pete Holsberg) writes: >I'd like to have nuucp with no passwd for anonymous uucp possibilities >but my SV/386 R3.2.2 insists on asking nuucp to choose a password! How >can I convince UNIX that nuucp doesn't need a password? > I think you need to disable the requirement for all logins. Not that you won't have password protection but any user will now be able to have a null password if they want. If this isn't a problem on your system then look at /etc/default/login. Add (or change) a line that says "PASSREQ=NO" and you should have what you want. -- D'Arcy J.M. Cain (darcy@druid) | D'Arcy Cain Consulting | I support gun control. West Hill, Ontario, Canada | Let's start with the government! + 416 281 6094 |
kherron@ms.uky.edu (Kenneth Herron) (10/26/90)
woods@eci386.uucp (Greg A. Woods) writes: >In article <1990Oct22.211639.14436@mccc.uucp> pjh@mccc.uucp (Pete Holsberg) writes: >> How can I convince UNIX that nuucp doesn't need a password? >Login as root, make sure no-one else is using the system (at least >make sure they don't run passwd, or chsh, etc.), and edit /etc/passwd. >Add a new line for nuucp, with a home directory of /usr/spool/uucppublic >[...] Please, this isn't necessary. Look up passmgmt(1) and passwd(1M). Together they give you all the control you can want over passwd and shadow, with no worries about what other users are doing. Passwd has an option just for your needs, -d as I recall. It sets the given ID to be without a password. Passwd has two man pages, be sure you look at passwd(1M), the second one. Now for a "style" issue: around here we give the uucp logins a home directory of /usr/lib/uucp. Where ever you put it, create a file there called .hushlogin. This prevents the usual signon messages from printing after the login succeeds. (If you put .hushlogin in /usr/spool/uucppublic, it'll get cleaned out eventually). Kenneth Herron
dcon@cbnewsc.att.com (david.r.connet) (10/26/90)
In article <1990Oct25.155651.16447@eci386.uucp>, woods@eci386.uucp (Greg A. Woods) writes: > In article <1990Oct22.211639.14436@mccc.uucp> pjh@mccc.uucp (Pete Holsberg) writes: > > I'd like to have nuucp with no passwd for anonymous uucp possibilities > > but my SV/386 R3.2.2 insists on asking nuucp to choose a password! How > > can I convince UNIX that nuucp doesn't need a password? > > Don't use sysadm (or face) to install new users, especially system type > accounts. Actually that's a little one-sided, but I never trust these > fancy system admin. type things! :-) > > Login as root, make sure no-one else is using the system (at least > make sure they don't run passwd, or chsh, etc.), and edit /etc/passwd. > Add a new line for nuucp, with a home directory of /usr/spool/uucppublic > and a shell of /usr/lib/uucp/uucico. Make the password field blank, > and choose a unique user-id, and unique group-id (if you don't already > have a uulogins (or something similar) group. Don't use the same > user-id or group as uucp. ...etc... Actually, the easiest way is to use the 'passwd' command. The '-d' option says no passwd. Hence: passwd -d nuucp (you just have to turn off aging now, which I'm not sure how. I just use the -x and -n options to set it forward a bit.) Dave Connet dcon@iwtng.att.com
alex@am.sublink.org (Alex Martelli) (10/27/90)
In <1990Oct22.211639.14436@mccc.uucp> pjh@mccc.uucp (Pete Holsberg) writes: >I'd like to have nuucp with no passwd for anonymous uucp possibilities >but my SV/386 R3.2.2 insists on asking nuucp to choose a password! How >can I convince UNIX that nuucp doesn't need a password? As root, run "passwd -d -x 7000 -n 7000 nuucp" and you should be ok for 20 years or so. A simpler call SHOULD work, according to the man entry, but in practice, on some machines, and depending on /etc/defaultish stuff, simpler invocations appear to fail (sometimes in DANGEROUS ways, such as unexpectedly expiring nuucp's password and asking nuucp to change it on next login, which does wonders for your uucp connectivity:-). This one has worked for me every time I have needed this functionality. -- Alex Martelli - (home snailmail:) v. Barontini 27, 40138 Bologna, ITALIA Email: (work:) staff@cadlab.sublink.org, (home:) alex@am.sublink.org Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
richard@pegasus.com (Richard Foulk) (10/27/90)
>Now for a "style" issue: around here we give the uucp logins a home >directory of /usr/lib/uucp. Where ever you put it, create a file >there called .hushlogin. This prevents the usual signon messages >from printing after the login succeeds. (If you put .hushlogin in >/usr/spool/uucppublic, it'll get cleaned out eventually). Not if you fix that damn /usr/lib/uucp/uudemon.cleanup script so it doesn't remove things like that. Scripts that blindly rm -f files just because they've been around a while have no place on MY machine. -- Richard Foulk richard@pegasus.com
richard@pegasus.com (Richard Foulk) (10/27/90)
>I think you need to disable the requirement for all logins. Not that you >won't have password protection but any user will now be able to have a >null password if they want. If this isn't a problem on your system then >look at /etc/default/login. Add (or change) a line that says "PASSREQ=NO" >and you should have what you want. Not true. If a user is given a password, passwd(1) will not allow him to replace it with a null password. -- Richard Foulk richard@pegasus.com
pjh@mccc.uucp (Pete Holsberg) (10/27/90)
In article <1990Oct26.140812.14028@cbnewsc.att.com> dcon@cbnewsc.att.com (david.r.connet) writes: =In article <1990Oct25.155651.16447@eci386.uucp>, woods@eci386.uucp (Greg A. Woods) writes: => In article <1990Oct22.211639.14436@mccc.uucp> pjh@mccc.uucp (Pete Holsberg) writes: => > I'd like to have nuucp with no passwd for anonymous uucp possibilities => > but my SV/386 R3.2.2 insists on asking nuucp to choose a password! How => > can I convince UNIX that nuucp doesn't need a password? => <Greg Woods' posting omitted> Greg, I never did see the original of that posting, but the problem lies in the Xenix-compatibility of SV/386 R3.2.2. = =Actually, the easiest way is to use the 'passwd' command. =The '-d' option says no passwd. Hence: = passwd -d nuucp =(you just have to turn off aging now, which I'm not sure how. =I just use the -x and -n options to set it forward a bit.) And of course you've edited the /etc/defaults/login file to remove the PASSREQ=YES line? Pete -- Prof. Peter J. Holsberg Mercer County Community College Voice: 609-586-4800 Engineering Technology, Computers and Math UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690 Internet: pjh@mccc.edu Trenton Computer Festival -- 4/20-21/91
jpr@jpradley.uucp (Jean-Pierre Radley) (10/28/90)
In article <1990Oct22.211639.14436@mccc.uucp> pjh@mccc.uucp (Pete Holsberg) writes: >I'd like to have nuucp with no passwd for anonymous uucp possibilities >but my SV/386 R3.2.2 insists on asking nuucp to choose a password! How >can I convince UNIX that nuucp doesn't need a password? I assume that the "insisting" comes from a mkuser or addusr or similar program? Anyways, what if you just give it a password and then edit it out of /etc/passwd? BTW, what's the point of 'nuucp' as a public, unpassworded access instead of just plain 'uucp'? -- Jean-Pierre Radley HIGH-Q jpr@jpradley CIS: 72160,1341
woods@eci386.uucp (Greg A. Woods) (10/29/90)
In article <1990Oct27.203150.13610@jpradley.uucp> jpr@jpradley.UUCP (Jean-Pierre Radley) writes: > In article <1990Oct22.211639.14436@mccc.uucp> pjh@mccc.uucp (Pete Holsberg) writes: > >I'd like to have nuucp with no passwd for anonymous uucp possibilities > >but my SV/386 R3.2.2 insists on asking nuucp to choose a password! How > >can I convince UNIX that nuucp doesn't need a password? > > I assume that the "insisting" comes from a mkuser or addusr or similar program? Actually, it appears AT&T SysVr3.2.2/386 has a xenix-like login, which has an option of insisting on a password. It also appears they went do default shadow passords. I hope the shadow password facility can be undone just as it can be in SysVr3.2/3b2 > BTW, what's the point of 'nuucp' as a public, unpassworded access instead of > just plain 'uucp'? By default, traditionally that is, "uucp" is an administrative account, and "nuucp" is a uucico, often without a password. Some vendors have given uucp a shell of uucico, eliminating the administrative account. I strongly recommend against this practice because of security reasons. The UUCP owner and administrator should be a seperate user-id and group-id from any uucico logins. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP +1-416-443-1734 [h] +1-416-595-5425 [w] VE3-TCP Toronto, Ontario CANADA
jackv@turnkey.tcc.com (Jack F. Vogel) (10/29/90)
In article <1990Oct27.203150.13610@jpradley.uucp> jpr@jpradley.UUCP (Jean-Pierre Radley) writes: >BTW, what's the point of 'nuucp' as a public, unpassworded access instead of >just plain 'uucp'? Because everything in /usr/lib/uucp including such things as Systems and Permissions is owned and readable by uucp. Would you like other sites snagging a copy of those files :-}. -- Jack F. Vogel jackv@locus.com AIX370 Technical Support - or - Locus Computing Corp. jackv@turnkey.TCC.COM
pjh@mccc.uucp (Pete Holsberg) (10/29/90)
In article <1990Oct27.203150.13610@jpradley.uucp> jpr@jpradley.UUCP (Jean-Pierre Radley) writes:
=I assume that the "insisting" comes from a mkuser or addusr or similar program?
Nope! It comes from login.
=
=Anyways, what if you just give it a password and then edit it out of
=/etc/passwd?
Login says, "bad boy! you ain't got no password. ya' better
get one RIGHT NOW or you ain't gettin' into this machine!"
It's a Xenix compatibility issue, as I understand it.
=BTW, what's the point of 'nuucp' as a public, unpassworded access instead of
=just plain 'uucp'?
uucp is the "root" of communications and owns enough stuff so that
an un-passworded uucp is an invitation to create trouble. (This
was pointed out to me in email.)
Pete
--
Prof. Peter J. Holsberg Mercer County Community College
Voice: 609-586-4800 Engineering Technology, Computers and Math
UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690
Internet: pjh@mccc.edu Trenton Computer Festival -- 4/20-21/91jeffl@comix.UUCP (Jeff Liebermann) (10/29/90)
In article <1990Oct27.081021.12021@pegasus.com>, richard@pegasus.com (Richard Foulk) writes: > >I think you need to disable the requirement for all logins. Not that you > >won't have password protection but any user will now be able to have a > >null password if they want. If this isn't a problem on your system then > >look at /etc/default/login. Add (or change) a line that says "PASSREQ=NO" > >and you should have what you want. > > Not true. If a user is given a password, passwd(1) will not allow him > to replace it with a null password. Agreed. Details as follows. In SCO 3.2.2 with C2 security (allegedly) turned off (relaxed) /etc/default/login includes PASSREQ=NO the passwd -d command correctly deletes the requirement for having a password. However, as soon as the user (or nuucp) logs in immediatly thereafter, login complains that they don't have a password and demands one. So much for that idea. At best, I was able to get the password set to a <cr>. For entertainment, I then started hacking at /tcb/files/auth/n/nuucp and /etc/passwd files directly. Same result. I can delete a password for a single attempt, but a password is demanded immediately thereafter. -- # Jeff Liebermann Box 272 1540 Jackson Ave Ben Lomond CA 95005 # (408)336-2558 voice (408)429-0483 digital pager WB6SSY CIS:73557,2074 # PC REPAIR & RF DESIGN uunet!comix!jeffl ucscc.ucsc.edu!comix!jeffl # universe!milky_way!solar_system!earth!na!us!uunet!comix!jeffl
rad@genco.bungi.com (Bob Daniel) (10/30/90)
In article <1990Oct25.155651.16447@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: >In article <1990Oct22.211639.14436@mccc.uucp> pjh@mccc.uucp (Pete Holsberg) writes: >> I'd like to have nuucp with no passwd for anonymous uucp possibilities >> but my SV/386 R3.2.2 insists on asking nuucp to choose a password! How >> can I convince UNIX that nuucp doesn't need a password? > >Don't use sysadm (or face) to install new users, especially system type >accounts. Actually that's a little one-sided, but I never trust these >fancy system admin. type things! :-) > You could use face to setup 'nuucp' and then edit '/etc/default/login' and enter 'PASSREQ=NO'. However, this would would apply to all logins. Also, in '/etc/shadow', the last two entries usually defaul to ':14:28' which mean you can't change the passwd within 14 days and must be changed after 28 days. Just remove those two number and password ageing will be disabled for that login. If you want to turn off passwd ageing for everyone, it can also be done in '/etc/default/login'. I don't remember the entry to make but it's in the SysAdm manual.
alex@am.sublink.org (Alex Martelli) (11/02/90)
jeffl@comix.UUCP (Jeff Liebermann) writes: ... >In SCO 3.2.2 with > C2 security (allegedly) turned off (relaxed) > /etc/default/login includes PASSREQ=NO >the passwd -d command correctly deletes the requirement for >having a password. However, as soon as the user (or nuucp) >logs in immediatly thereafter, login complains that they don't >have a password and demands one. So much for that idea. At Have you tried the hack I previously suggested, that is to run, as root, "passwd -d -x 7000 -n 7000 nuucp"? It's worked for me on all Sysv/386 Unices I have tried it on, but I have not tried SCO. -- Alex Martelli - (home snailmail:) v. Barontini 27, 40138 Bologna, ITALIA Email: (work:) staff@cadlab.sublink.org, (home:) alex@am.sublink.org Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).
marlor@dream.sublink.ORG (Marco Lorenzini) (11/03/90)
In <1990Nov01.183404.285@am.sublink.org> alex@am.sublink.org (Alex Martelli) writes: >jeffl@comix.UUCP (Jeff Liebermann) writes: > ... >>In SCO 3.2.2 with >> C2 security (allegedly) turned off (relaxed) >> /etc/default/login includes PASSREQ=NO >>the passwd -d command correctly deletes the requirement for >>having a password. However, as soon as the user (or nuucp) >>logs in immediatly thereafter, login complains that they don't >>have a password and demands one. So much for that idea. At >Have you tried the hack I previously suggested, that is to run, as >root, "passwd -d -x 7000 -n 7000 nuucp"? It's worked for me >on all Sysv/386 Unices I have tried it on, but I have not tried SCO. No, on Sco Unix your hack don't work also with C2 security relaxed. With Sco any user MUST have own password if want to be able to log on the system. Marco. -- *********** Marco Lorenzini * FAX +39.51.752643 * * DREAM * marlor@gear.sublink.ORG * VOICE +39.51.750365 * *********** (1200-2400 MNP 4 - 9600 PEP) * TELEX 521116 LSMECC *
jpr@jpradley.uucp (Jean-Pierre Radley) (11/05/90)
In article <1990Oct28.220148.13034@mccc.uucp> pjh@mccc.edu (Pete Holsberg) writes: >In article <1990Oct27.203150.13610@jpradley.uucp> jpr@jpradley.UUCP (Jean-Pierre Radley) writes: >=BTW, what's the point of 'nuucp' as a public, unpassworded access instead of >=just plain 'uucp'? > > uucp is the "root" of communications and owns enough stuff so that > an un-passworded uucp is an invitation to create trouble. (This > was pointed out to me in email.) On my machine, uucp, uucpmgr, Umurphy, Uhombre, Utrigere, and many others all have the same uid/gid. Is this bad? Is the scheme for nuucp to give it a different uid/gid? -- Jean-Pierre Radley HIGH-Q jpr@jpradley CIS: 72160,1341
shwake@raysnec.UUCP (Ray Shwake) (11/05/90)
jpr@jpradley.uucp (Jean-Pierre Radley) writes: >On my machine, uucp, uucpmgr, Umurphy, Uhombre, Utrigere, and many others all >have the same uid/gid. >Is this bad? >Is the scheme for nuucp to give it a different uid/gid? Had an experience several years ago involving uucp communications between a UNIX PC 7300 and, as I recall, an Altos 3068. A problem which bedeviled me for days was finally traced to identical uid's for both the uucp shell and nuucp daemon logins. It's possible you may experience no problem giving all the uucico logins the same uid, but keep in mind that the shell will consider the name assigned to the first of those uid's to be the owner of all files owned by that uid. Having an identical gid (say, "uucp") should be no problem.
pjh@mccc.uucp (Pete Holsberg) (11/06/90)
In article <1990Nov4.213500.13805@jpradley.uucp> jpr@jpradley.UUCP (Jean-Pierre Radley) writes:
=On my machine, uucp, uucpmgr, Umurphy, Uhombre, Utrigere, and many others all
=have the same uid/gid.
=Is this bad?
Well, you could be jailed! :-)
=Is the scheme for nuucp to give it a different uid/gid?
I give all the "uucico accounts" on mccc different uids but put
them in the same group. This allows me to keep track of who does what
and when.
Pete
--
Prof. Peter J. Holsberg Mercer County Community College
Voice: 609-586-4800 Engineering Technology, Computers and Math
UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690
Internet: pjh@mccc.edu Trenton Computer Festival -- 4/20-21/91rwhite@nusdecs.uucp (0257014-Robert White(140)) (11/08/90)
In article <1990Nov4.213500.13805@jpradley.uucp> jpr@jpradley.UUCP (Jean-Pierre Radley) writes: >On my machine, uucp, uucpmgr, Umurphy, Uhombre, Utrigere, and many others all >have the same uid/gid. >Is this bad? >Is the scheme for nuucp to give it a different uid/gid? If you wan to do much of the stuff with the permissions file, especially reguarding VALIDATE, you will want to have a different uid number for each group of machines. I use uucp:5:5; nuucp:10:10 (<=defaults) and x:11:10; y:12:10 etc... I find that different user IDs and the same group ID to be most convinent. Especially when I get around to RFS stuff (later) ******************************************************************* Robert White | Not some church, and not the state, Network Administrator | Not some dark capricious fate. National University | Who you are, and when you lose, crash!nusdecs!rwhite | Comes only from the things you chose. (619) 563-7140 (voice) | -- me. *******************************************************************
jmm@eci386.uucp (John Macdonald) (11/08/90)
In article <1990Nov4.213500.13805@jpradley.uucp> jpr@jpradley.UUCP (Jean-Pierre Radley) writes: | |On my machine, uucp, uucpmgr, Umurphy, Uhombre, Utrigere, and many others all |have the same uid/gid. |Is this bad? |Is the scheme for nuucp to give it a different uid/gid? You should have a different uid for uucp - it ought to be used for administration activities and not for uucico to other systems. (Except that you have uucpmgr, which seems to be taking its place, so I guess that on your system the uucp account serves the purpose more commonly provided by a nuucp account - undifferentiated uucico.) Whether you need a separate uid for the nuucp acount (uucp in your case) and the various Usystem accounts is a function of your flavour of Unix and uucp. I have seen some setups where they must be the same (or else permissions would get in the way) and others where the uids must be different (or else the uucp software would think that the login name was whichever of them came first in /etc/passwd) and the gids would have to be the same. Since you (presumably) have not been getting complaints from uucp failing to distinguish the login names correctly, there is no need to change anything there. -- Cure the common code... | John Macdonald ...Ban Basic - Christine Linge | jmm@eci386
walter@mecky.UUCP (Walter Mecky) (11/09/90)
In article <1990Nov03.153644.549@dream.sublink.ORG> marlor@dream.sublink.ORG (Marco Lorenzini) writes:
< No, on Sco Unix your hack don't work also with C2 security relaxed.
< With Sco any user MUST have own password if want to be able to log
< on the system.
Wrong! With the SLS unx167 installed you can delete a password with
"passwd -d". Believe me.
--
Walter Mecky [ walter@mecky.uucp or ...uunet!unido!mecky!walter ]sys0001@dircon.uucp (11/11/90)
In article <1990Nov03.153644.549@dream.sublink.ORG> marlor@dream.sublink.ORG (Marco Lorenzini) writes: >In <1990Nov01.183404.285@am.sublink.org> alex@am.sublink.org (Alex Martelli) writes: > >>jeffl@comix.UUCP (Jeff Liebermann) writes: >> ... >>>In SCO 3.2.2 with >>> C2 security (allegedly) turned off (relaxed) >>> /etc/default/login includes PASSREQ=NO >>>.... However, as soon as the user (or nuucp) >>>logs in immediatly thereafter, login complains that they don't >>>have a password and demands one. > >>Have you tried the hack I previously suggested, that is to run, as >>root, "passwd -d -x 7000 -n 7000 nuucp"? >No, on Sco Unix your hack don't work also with C2 security relaxed. >With Sco any user MUST have own password if want to be able to log >on the system. > Not true. Use the sysadmsh, select Accounts/User/Examine, enter the username from which you want to remove the password. Select "Password" from the list of parameters displayed. Then, on the Password selection screen, select: - No password required Then go down to "Current password status" and select Remove. Finally, select the No option of "Change Password at Login". Do keep PASSREQ=NO in /etc/default/login. -- sys0001@dircon.UUCP or sys0001%dircon@ukc.ac.uk
rhealey@digibd.com (Rob Healey) (11/29/90)
In article <1990Nov03.153644.549@dream.sublink.ORG> marlor@dream.sublink.ORG (Marco Lorenzini) writes: >In <1990Nov01.183404.285@am.sublink.org> alex@am.sublink.org (Alex Martelli) writes: > >No, on Sco Unix your hack don't work also with C2 security relaxed. >With Sco any user MUST have own password if want to be able to log >on the system. > While I haven't tried nuucp, I've set up SCO UNIX 3.2v2.0 systems where ROOT doesn't have a password and things work just fine. Maybe it's that psuedo users, like nuucp, must have passwords? Try opening the nuucp account as a user rather than a psuedo account. By the way, these systems are used in a test lab so it doesn't matter that root has no password... -Rob Speaking for self, not company.