When machines boot, they need to authenticate to connect to
resources such as the file server.  Therefore there has to
be some user id that the machine authenticates as.  Cpu
servers authenticate as whatever you typed into the
'authid:' prompt the first time you brought it up (ou
can change that later with auth/wrkey).  Terminals
authenticate as you after you answer the 'user:' and
'password:' prompts.

On our systems, all the cpu servers (and the file server as
well) authenticate as the same user, 'bootes'.  That's just a
hack that lets us bring up the auth server 'file system'-less.
You don't need to do that if your auth server has its own file
system.

If a machine is authenticated as X and you want attach to any
remote resource from it as user Y, you need

	hostid=X
		uid=Y

or

	hostid=X
		uid=*

in /lib/ndb/auth.  That pertains to any machine, be it terminal
or cpu server.  The relation in /lib/ndb auth is, ala Abadi-Lampson, a
'speaks for' relation, i.e., it says that that id X may speak
for id Y.  Given a request from 'Y', the auth server will return
to it a ticket to act as 'X'.

The relation

	hostid=X
		uid=X

is implicit.

Therefore, you want to limit who can speak for whom.  The relation

	hostid=X
		uid=*

makes X a super-user of sorts since he can now attach to any resource
as anyone.  That's the main reason we run servers as 'none', so that
someone mounting an attack that subverts the server doesn't gain
much more power than the ability to kill other servers.  Ideally,
we shouldn't even let 'none' debug other 'none' processes since that's
a way to learn secrets hidden inside the 'none' server processes.