From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <200007261634.MAA15529@smtp4.fas.harvard.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] INIT and AUTH - Was: X11 on 3rd Edition
From: "Russ Cox" <rsc@plan9.bell-labs.com>
Date: Wed, 26 Jul 2000 12:34:16 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: eac1edb2-eac8-11e9-9e20-41e7f4b1d025

	Another difference I noticed between 2ed and 3ed is the fact that most
	services on a CPU server now run as "none".  As mentioned, that is a
	useful security precaution, and would be usefully documented for the
	services involved.  Presumably, something along these lines is
	happening: if the service is found in /rc/bin/service, it is run under
	id "none", if in /rc/bin/service.auth (and elsewhere?), the host id is
	used.

If its in a directory specified with listen -d, it's
not trusted and runs as none.  Things in a directory
specified with listen -t are trusted, and run as
whoever ran listen.  Listen(8) in my second edition
manual mentions this.  I'm pretty sure it existed then.

	Here, I think I start getting confused: who looks at /lib/ndb/auth?
	And where there's more than one, which one is used?  I would suggest,
	unless I'm missing the point, that there ought to be a single point of
	such authority, at least for a single authentication domain.  Is this
	at all possible to implement securely?  It would certainly be a bit of

The only /lib/ndb/auth that matters is the one
that auth.srv and guard.srv (which run on the
authentication server) see.

Russ