Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!swrinde!ucsd!pacbell.com!pacbell!rtech!ingres!seg
From: seg@ingres.com (scott e garfinkle)
Newsgroups: comp.mail.uucp
Subject: Re: problem with inbound anonymous uucp sessions
Keywords: Esix Sysvr3 UUCP anonymous
Message-ID: <1990Oct4.153205.26354@ingres.Ingres.COM>
Date: 4 Oct 90 15:32:05 GMT
References: <2658@sud509.ed.ray.com> <2719@crdos1.crd.ge.COM>
Reply-To: seg@beaver.Ingres.COM (scott e garfinkle)
Organization: Ingres Corp.
Lines: 21

In article <2719@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes:
>In article <2658@sud509.ed.ray.com> heiser@tdw201.ed.ray.com writes:
>
>| I currently have no password on the nuucp account.  When there was a
>| password, no systems were able to get in.  Now there is one system that
>| can, but others can't.  This doesnt' seem to make any sense...
>
>| # grep uucp /etc/passwd
>| uucp:x:5:5:0000-uucp(0000):/usr/lib/uucp:
>| nuucp:x:10:10:0000-uucp(0000):/usr/spool/uucppublic:/usr/lib/uucp/uucico
>| ...
>
>  Looks to me as though nuucp is "no login" now. That's what the :x: (or
>any other one character) does. If you change that to :: you will have a
>start at it.

Nah, I don't think so.  In Esix, as most SVR3.2 systems, I think, login has
SHADOW turned on and the password (and aging) is stored in /etc/shadow.
Anyway if at least one system can get in on the nuucp account,
then the problem will lie in the ~uucp/Permissions file.
	-scott e. garfinkle