From: presotto@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] auth(6)
Date: Thu, 20 Jul 2000 08:10:57 -0400 [thread overview]
Message-ID: <200007201211.IAA04506@cse.psu.edu> (raw)
[-- 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?
next reply other threads:[~2000-07-20 12:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-07-20 12:10 presotto [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-07-20 12:10 Russ Cox
2000-07-20 9:22 Nigel Roles
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200007201211.IAA04506@cse.psu.edu \
--to=presotto@plan9.bell-labs.com \
--cc=9fans@cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).