Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site down.FUN
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!down!honey
From: honey@down.FUN (code 101)
Newsgroups: net.bugs.uucp
Subject: Re: System V introduces yet another inconsistency
Message-ID: <464@down.FUN>
Date: Thu, 7-Mar-85 07:47:32 EST
Article-I.D.: down.464
Posted: Thu Mar  7 07:47:32 1985
Date-Received: Fri, 8-Mar-85 03:46:40 EST
References: <454@lsuc.UUCP> <530@rlgvax.UUCP> <27@axiom.UUCP>
Organization: Princeton University, EECS
Lines: 33

steve claims certain benefits of having different logins for each
neighbor machine.  this is impractical.  i have published princeton's
uucp dope many times:  i want as many people as possible to call me,
even though i won't call them back if they're too far away.  (pathalias
solves the reply problem.)  i'm not about to add thousands of
/etc/passwd entries.

what \is/ practical is to break the universe into equivalence classes
of capabilities/permissions.  in my case, i use four uucp logins:

	login	write	read	commands
	-----	-----	----	--------
	uucp	PUBDIR	nil	rmail
	nuucp	PUBDIR	nil	rmail, rnews, unbatch, cunbatch
	tuucp	PUBDIR	PUBDIR	ditto + uusend, uucp
	luucp	all	all	all

i protect the passwds on all but the first (by giving them to people i
trust), and by using the VALIDATE option in the Permissions file.

instead of using who to see if a call is active, i ls /usr/spool/locks
(or i run uustat -p).  and since honey danber produces separate logs
for each host, it's easy to gauge the frequency and reliability of a
connection.  besides, the honey danber conn() is perfect, and doesn't
demand the TLC we are all used to providing.

	peter

ps:  here's my Systems (was L.sys) data.  call me anytime.

princeton Any ACU 1200	trenton4522906 "" "" in:--in: uucp word uuprince
princeton Any ACU 1200	trenton4528678 "" "" in:--in: uucp word uuprince
princeton Any ACU 1200	trenton6831286 "" "" in:--in: uucp word uuprince