9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Lucio De Re <lucio@proxima.alt.za>
To: russcox@gmail.com, 9fans@cse.psu.edu
Subject: Re: [9fans] 9grid.us
Date: Wed, 25 May 2005 07:20:15 +0200	[thread overview]
Message-ID: <716b83c2525c28fc93f44f32199961fe@proxima.alt.za> (raw)
In-Reply-To: <ee9e417a0505242154412259a6@mail.gmail.com>

> Here the cpu authentication is succeeding but then the
> file server doesn't allow the mount because the user is unknown.
> You have to add the user.  This is unfortunate for 9grid purposes
> but it's the way it is.  I suspect you are also going to need 
> your cpu server's host id to be able to speak for the incoming users
> in order to mount the root file system before there is a /mnt/factotum
> for the user, which is also unfortunate.  There are definitely still
> issues to be resolved -- the hooks for cross-domain authentication 
> are there in factotum but the rest of the system will need some work.

Would it be out of the question to add an option to Fossil that
constructs users on the fly?  Or perhaps the type of utility used on
sources to create new users, but limited to entries authenticated from
a /lib/ndb/auth-listed authentication source?  Something that is done
preliminary to establishing a CPU connection so it is executed in an
authoritative namespace and with sensible defaults?

What strikes me is that if one delegates authentication to sources,
one may as well accept its authority insofar as the existence of users
is concerned.  One may want to use a dedicated fileserver to the
purpose, so as to protect one's own network, but that only mirrors
what sources already does.

What are the security implications here?

++L



  reply	other threads:[~2005-05-25  5:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-25  4:39 YAMANASHI Takeshi
2005-05-25  4:54 ` Russ Cox
2005-05-25  5:20   ` Lucio De Re [this message]
     [not found]   ` <1c63862e8858694ce3b83f5d372ad789@proxima.alt.za>
2005-05-25  5:32     ` Russ Cox
2005-05-25  6:11       ` Lucio De Re
2005-05-25  6:09         ` Russ Cox
2005-05-25  6:27           ` Lucio De Re
2005-05-25  6:28       ` Lucio De Re
2005-05-25  9:04         ` C H Forsyth
2005-05-25  9:32           ` Lucio De Re
  -- strict thread matches above, loose matches on Subject: below --
2005-05-25  7:26 YAMANASHI Takeshi
2005-05-25  6:34 YAMANASHI Takeshi
2005-05-25  6:56 ` Lucio De Re
2005-05-25  2:33 YAMANASHI Takeshi
2005-05-25  2:39 ` Russ Cox
2005-05-25  1:52 YAMANASHI Takeshi
2005-05-25  2:02 ` Eric Van Hensbergen
     [not found] <237c0daf7d8dd5561cf95744c7516fd0@orthanc.cc.titech.ac.jp>
2005-05-24 12:56 ` Eric Van Hensbergen
2005-05-22 17:14 Eric Van Hensbergen
2005-05-22 17:21 ` Russ Cox
2005-05-23 14:03   ` Eric Van Hensbergen
2005-05-24  8:13     ` Richard Miller

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=716b83c2525c28fc93f44f32199961fe@proxima.alt.za \
    --to=lucio@proxima.alt.za \
    --cc=9fans@cse.psu.edu \
    --cc=russcox@gmail.com \
    /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).