Re: [9fans] identity/ownership

Re: [9fans] identity/ownership

[Fco.J.Ballesteros]

I'm for sure missing something...

I only have /lib/ndb/auth; no /lib/ndb/authid
Such settings  work for me.
Auth(6) only speaks about /lib/ndb/auth

So, is authid a different thing? Is it the old auth?
Should I revisit my configuration? or is it just a name
change?

Re: [9fans] identity/ownership

[Lucio De Re]

On Wed, Nov 07, 2001 at 10:03:08AM +0100, Fco.J.Ballesteros wrote:
>
> So, is authid a different thing? Is it the old auth?
> Should I revisit my configuration? or is it just a name
> change?
>
I think it's a case of "lapsus calami" on presotto's part.  It is
conceivable that "authid" may be interchangeable with "auth" but I'm
not even going to try :-)

++L

Re: [9fans] identity/ownership

[presotto]

On Wed Nov  7 00:28:21 EST 2001, lucio@proxima.alt.za wrote:
> ... I presume
> at Bell Labs it is conventional for all CPU servers to have the same
> owner?  I set up the second CPU server specifically for Inferno, so
> that caused me to have a requirement for two hostids.

At the labs, within an authentication domain, they use the same owner
on all file systems and cpu servers, there's not much reason to do
differently.

It also makes restarting when some disaster happens a little more
robust.  If a cpu server has the same owner/key as the file server
then, should there be no auth server running, it can craft its own
ticket to authenticate the attach.  There's a hack in the code to
do that.  That way, all the cpu servers can also be diskless.

Re: [9fans] identity/ownership

[presotto]

[-- Attachment #1: Type: text/plain, Size: 83 bytes --]

My fault, I really meant /lib/ndb/auth.  I just type
authid too much these days.

[-- Attachment #2: Type: message/rfc822, Size: 1402 bytes --]

From: Fco.J.Ballesteros <nemo@plan9.escet.urjc.es>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] identity/ownership
Date: Wed, 7 Nov 2001 10:03:08 +0100
Message-ID: <20011107090313.43ACF199E8@mail.cse.psu.edu>

I'm for sure missing something...

I only have /lib/ndb/auth; no /lib/ndb/authid
Such settings  work for me.
Auth(6) only speaks about /lib/ndb/auth

So, is authid a different thing? Is it the old auth?
Should I revisit my configuration? or is it just a name
change?

Re: [9fans] identity/ownership

[Lucio De Re]

On Tue, Nov 06, 2001 at 10:33:08AM -0500, presotto@closedmind.org wrote:
Got it!  :-)
>
> 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.
>
Settled.  I was thoroughly confused for a long, long time.  I presume
at Bell Labs it is conventional for all CPU servers to have the same
owner?  I set up the second CPU server specifically for Inferno, so
that caused me to have a requirement for two hostids.

> 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

Putting it another way, this is authentication for remote access to
the CPU server, right?

> 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.
>
Only later did I pick up the crucial factor, see below.

> The 'speaks for' relation in /lib/ndb/authid looks like what you
*** you consistently use /lib/ndb/authid,
*** but I take it you mean /lib/ndb/auth
> 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'.
>
I was going to ask about the default, I had overlooked it until
right at this moment.

> 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
>
It would seem hard to avoid without a lot of pain and suffering, but
it is good to see it spelled out.

> 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
>
This bit I hadn't understood at all.  I thought the fileserver, not
the authserver, needed the relationship.  Why, I'm not sure, but now
it all makes a lot of sense.  Multiple fileservers are more a pain
than a gain, it would seem, I'm interested in opinions on this score,
specially if the new fileserver is still going to be released.

>   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.

It does now, after I checked each of the conditions you so nicely
presented above, including making sure that the auth server and CPU
server agreed on inferno's password.

I really appreciate your help, I've been muddled up on this issue for
a long time and getting it cleared up was well worth the embarrassment
of asking such stupid questions :-)

Thanks to forsyth too, for his help.

++L

Re: [9fans] identity/ownership

[presotto]

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.

Re: [9fans] identity/ownership

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 48 bytes --]

because you speak for yourself in that case.


[-- Attachment #2: Type: message/rfc822, Size: 2005 bytes --]

To: 9fans@cse.psu.edu
Subject: Re: [9fans] identity/ownership
Date: Tue, 6 Nov 2001 15:45:08 +0200
Message-ID: <20011106154506.H25942@cackle.proxima.alt.za>

On Tue, Nov 06, 2001 at 01:44:03PM +0000, forsyth@vitanuova.com wrote:
>
> what are the non-comment lines in /lib/ndb/auth on the 3rd edition system?

----- cut here -----
----- cut here -----

:-)

I thought it ought to be something simple, but why then do I get
successful access from my workstation?

++L

Re: [9fans] identity/ownership

[Lucio De Re]

On Tue, Nov 06, 2001 at 03:45:08PM +0200, Lucio De Re wrote:
>
> On Tue, Nov 06, 2001 at 01:44:03PM +0000, forsyth@vitanuova.com wrote:
> >
> > what are the non-comment lines in /lib/ndb/auth on the 3rd edition system?
>
> ----- cut here -----
> ----- cut here -----
>
I copied the 2ed /lib/ndb/auth to the 3ed fileserver, to seemingly no
avail.  This had me puzzled before, originally I had hostid=fickle in
the file, but after re-reading the documenttion decided to change it
to hostid=proxima, where fickle is the "sys" name for the CPU and AUTH
server (2ed) and proxima is the "owner" of the server.

For some peculiar reason, either seems to work with the 2ed
fileserver.  Is this possible?  Before I change the 3ed /lib/ndb/auth
to try again, can somebody point me to an authoritative statement as
to where the "hostid" really resides?

And, to repeat myself, why do I successfully access the 3ed filserver
from my workstation despite incorrect information in /lib/ndb/auth?

For the curious, the current values in /lib/ndb/auth are

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

(indentation for effect, not in file).

++L

Re: [9fans] identity/ownership

[Lucio De Re]

On Tue, Nov 06, 2001 at 01:44:03PM +0000, forsyth@vitanuova.com wrote:
>
> what are the non-comment lines in /lib/ndb/auth on the 3rd edition system?

----- cut here -----
----- cut here -----

:-)

I thought it ought to be something simple, but why then do I get
successful access from my workstation?

++L

Re: [9fans] identity/ownership

[forsyth]

what are the non-comment lines in /lib/ndb/auth on the 3rd edition system?

[9fans] identity/ownership

[Lucio De Re]

My Plan 9 network is a bit of a jumble:  I have a 2ed fileserver
with the 2ed system on "main" and the 3ed system on "other".  The
status of both these filesystems is a bit dated, but it is workable.

I have a second fileserver, running a 3ed kernel, possibly not as
recent as it could be.  This serves only a 3ed filesystem as "main"
(and "dump" which I haven't quite come to grips with properly yet).
The filesystem itself is pretty much up to date.

I then have a 2ed compute server which also provides authentication
and naturally uses the 2ed filesystem.

A 3ed compute server used to mount the 3ed filesystem ("other") on
the 2ed fileserver, but now uses the second fileserver.

My workstation is even more messy: it mounts the 3ed filesystem
from the 2ed fileserver and runs as a somewhat dated 3ed workstation.

Where things become obscure is when I connect from the workstation
to the 3ed CPU server and gain access to the 3ed filesystem but
don't seem to have write permissions even in my home directory
there.

Mounting the same filesystem onto the workstation doesn't have such
a problem.

The same entry for "lucio" has at least the same numeric index in
all three /adm/users files and it would seem that I am "lucio" in
all instances, so what should I inspect to find out why I have no
permissions in this particular instance?  Am I being surreptitiously
replaced by "none"?  How do I find out?  /dev/user contains "lucio"
and so does /dev/hostowner.  I see that /dev/hostdomain, if relevant,
is empty.  What else would be worth checking?

I haven't been able to coax the 2ed CPU server to let me connect
to it from the 3ed workstation (ocpu notwithstanding, the devs
don't fit - more's the pity, 'cause I'd like to use art, catclock,
etc.), so I can't tell what type of access I would have from there.

++L