Re: [9fans] auth(6)

Re: [9fans] auth(6)

[presotto]

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

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.

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

From: "Nigel Roles" <nigel@cotswold.demon.co.uk>
To: 9fans@cse.psu.edu
Subject: [9fans] auth(6)
Date: Thu, 20 Jul 2000 10:22:07 +0100
Message-ID: <3976D2CF.2800.2ED3F73D@localhost>

I am intrigued by the /lib/ndb/auth example on auth(6) viz.

hostid=bootes
	uid=!sys uid=!adm uid=*

Bootes is typically a fileserver, but I feel this doesn't make sense
in this case. Authentication is about convincing a fileserver that
a client may speak for a userid, so should I think of bootes 
as a terminal/cpu server in this context?

The long and short is

1.	if I want to auth/login on my terminal (T) as user (U) do I need
   
	hostid=T
		uid=U

	in my /lib/ndb/auth?

2.	if I want to cpu(1) from my terminal to my cpu server (C), do I
	need

	hostid=C
		uid=!sys uid=!adm uid=*

	even if it is also the authentication server?

Re: [9fans] auth(6)

[Russ Cox]

  The long and short is

  1.	if I want to auth/login on my terminal (T) as user (U) do I need
   
  	hostid=T
  		uid=U

  	in my /lib/ndb/auth?


When you log into your terminal at boot time
as U, T=U.  If you want to be someone else (V)
while logged in as U, you need
	hostid=U
		uid=V
hostid might be more understandable as "hostuid".

  2.	if I want to cpu(1) from my terminal to my cpu server (C), do I
  	need

  	hostid=C
  		uid=!sys uid=!adm uid=*

Yes.

  	even if it is also the authentication server?

Yes.  The auth server is a process that interprets
the rules (among other things).  It doesn't distinguish
itself (at least, not in this regard) from other
CPU servers.

Russ

[9fans] auth(6)

[Nigel Roles]

I am intrigued by the /lib/ndb/auth example on auth(6) viz.

hostid=bootes
	uid=!sys uid=!adm uid=*

Bootes is typically a fileserver, but I feel this doesn't make sense
in this case. Authentication is about convincing a fileserver that
a client may speak for a userid, so should I think of bootes 
as a terminal/cpu server in this context?

The long and short is

1.	if I want to auth/login on my terminal (T) as user (U) do I need
   
	hostid=T
		uid=U

	in my /lib/ndb/auth?

2.	if I want to cpu(1) from my terminal to my cpu server (C), do I
	need

	hostid=C
		uid=!sys uid=!adm uid=*

	even if it is also the authentication server?