From mboxrd@z Thu Jan  1 00:00:00 1970
From: presotto@closedmind.org
To: 9fans@cse.psu.edu
Subject: Re: [9fans] identity/ownership
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20011106153311.5126A199BB@mail.cse.psu.edu>
Date: Tue,  6 Nov 2001 10:33:08 -0500
Topicbox-Message-UUID: 1689ca5e-eaca-11e9-9e20-41e7f4b1d025

I'm not entirely sure what your situation is.  However, here's
the rules:

Define `hostowner' as the id of the user the host is running as, i.e.,
the contents of /dev/hostowner.  On a terminal the user name and
pawword are prompted for, the user name becoming the hostowner.
On a PC they come from NVRAM, a disk partition called nvram, or
are typed in at boot.  Cat /dev/hostowner to be sure.

Call 'user' the user authenticating from a remote machine.

If 'hostowner' and 'user' both exist in /mnt/keys on the auth
server with the same keys entered into their respective machines,
then 'user' can successfully authenticate to the cpu and a
process will be started there for him.  However, any remote
resources that process now attaches must be authenticated.
Since the user's key is not on the cpu server, the cpu server
has to speak for the user in the attach.  For this to happen
the auth server has to have a 'speaks for' relation in its
/lib/ndb/authid that allows this.

The 'speaks for' relation in /lib/ndb/authid looks like what you
said you did:

hostid=proxima
	uid=!sys uid=!adm uid=*

That means that on a system owned by 'proxima', 'proxima' is allowed
to speak for anyone except sys and adm.  If 'user' has
successfully authenticated to the cpu server, the cpu
server should be able to authenticate 'user' in any mount
of a remote file server.  Lacking that relation, you will
get attached as 'none'.

There is an also implicit 'speaks for' relation, i.e., anyone can speak for
themselves.  Therefore, you don't need the 'speaks for' relation

hostid=lucio
	uid=lucio

That's why you can connect to your terminal whose hostowner is
you and be able to successfully authenticate to remote resources.


This all explains your first message but not your most recent.  If

- have added to the /lib/ndb/authid on the filesystem used by the
  auth server

  hostid=proxima
	uid=!sys uid=!adm uid=*

AND

- the contents of /dev/hostowner on the cpu server is 'proxima

AND

- all the systems use the same auth server

Then it all should have worked.