Re: [9fans] 9grid.us

Re: [9fans] 9grid.us

[YAMANASHI Takeshi]

> > So, the only key the factotum(*) has is your sources' key?
 :
> I believe that is correct, yes.  Russ said what was important was that
> it be the first key.

This works well on a standalone cpu server, but seems not work
on a diskless cpu server.  The file server seems not happy and
the following error appears on fscons:

	attach main as XXX: unknown user 'XXX'

How is the authentication different from diskless to standalone?
-- 

Re: [9fans] 9grid.us

[Russ Cox]

> How is the authentication different from diskless to standalone?

The difference is that standalone doesn't authenticate to
its own file server.  The file server trusts the local connection
in order to bootstrap.

You need to add a factotum key for the file server.  If you don't
want clients to be able to authenticate against that key, then
you should add "role=client" to it, to mark that it's only to be
used in client role (e.g., when accessing the file server).

Russ

Re: [9fans] 9grid.us

[Lucio De Re]

> it's fine to be tempted by cakes or cream, but not by that thing.

It appeals to the latent fascist in me.  Last night I discovered some
papers in my late mother's belonging, with Mussolini's signature on
them, maybe it in^H^Haffected me ;-)

More seriously, "if you can't lick them, join them" applies here.  And
from you, with all the hard work you put into Inferno for the precise
same purpose...

And Mark made a whole lot of money out of it, to boot.

++L

Re: [9fans] 9grid.us

[C H Forsyth]

>>I'm tempted by the X.509 certificate approach

it's fine to be tempted by cakes or cream, but not by that thing.

Re: [9fans] 9grid.us

[YAMANASHI Takeshi]

On Wed May 25 15:45:17 JST 2005, Lucio De Re wrote:
> > 9grid.us allows me to login and a none access to its local filesystem.
 :
> Wouldn't this imply a very complicated namespace?  And the risk of
> attack from the other side?

I don't know about the complicated namespace... but
you can restrict the namespace you export by "cpu -P".
-- 

Re: [9fans] 9grid.us

[Lucio De Re]

> 9grid.us allows me to login and a none access to its local filesystem.
> That might be enough for 9grid purposes.  9grid users should have their
> filesystem under /mnt/term or they can use ramfs for faster access.

Wouldn't this imply a very complicated namespace?  And the risk of
attack from the other side?  Yuck, I can't think straight, specially
when none enters the picture.

++L

Re: [9fans] 9grid.us

[YAMANASHI Takeshi]

Thanks for the detailed explanation, Russ.
It will take a little while until I digest the whole things.

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

9grid.us allows me to login and a none access to its local filesystem.
That might be enough for 9grid purposes.  9grid users should have their
filesystem under /mnt/term or they can use ramfs for faster access.
-- 

Re: [9fans] 9grid.us

[Lucio De Re]

> P.S. The type of utility used on sources is not much more than
> two tin cans and a piece of string.

It's effective, if a touch indiscriminate.  It probably will lead to
DoS eventually, which is why I'm tempted by the X.509 certificate
approach.  But of course I have no idea how to distribute
certificates, I'll have to renew my acquaintance with Mark
Shuttleworth (I _do_ know him, but I'm not being serious), before I
can make any serious suggestions.

++L

Re: [9fans] 9grid.us

[Lucio De Re]

> I was not suggesting they be ephemeral.  I just was suggesting
> that the behavior be that in the absence of evidence to the 
> contrary, the user name foo maps to the disk uid foo.

I agree unreservedly, as it's the simplest and therefore most likely
to work.

I added the type of complications that are made necessary by the
somewhat uncooperative nature of Internet visitors.  Ephemeral
accounts would have their place, too, I think, whether it would be the
default or the exception.  Maybe you need to log in a second time to
collect the signature on the certificate that was issued first time
around (says he, without stopping to think - don't shoot!).

++L

Re: [9fans] 9grid.us

[Lucio De Re]

> For something
> like a 9grid, maybe you're willing to give that up in order to
> avoid creating accounts explicitly.

The accounts exist once they are used, so I think the implicit
creation is not likely to be entirely transparent.  One could consider
ephemeral userids and arrange the dump accordingly, but I think most
9grid users would prefer to have at least some permanent resources.
But maybe that's not even a requirement.  Expiry certainly would be
nice, specially to prevent denials of service.  I guess the problem is
not a new one.

In general, in a promiscuous environment, I tend to think that mapping
convenient handles to obscene^H^H^Hure userids is preferable to the
contention involved.  But one would need a proper "retirement"
procedure to free a name, which I seem to recall is part of the fossil
implementation.  After all, if boyd maps to mxyzptlk, it would
probably suffice to rename it !mxyzptlk to be sure no one acquires it
once it's retired, specially if the internal name is not readily
visible beyond the boundaries of the server.

I guess someone had better write some code, now.  It won't be me in
the immediate future, Russ, but you've certainly been extremely
helpful and encouraging.

++L

PS: Silly me, I keep thinking about issuing 9grid X.509 certificates,
but I'm loath to mention it.

Re: [9fans] 9grid.us

[Russ Cox]

> The accounts exist once they are used, so I think the implicit
> creation is not likely to be entirely transparent.  One could consider
> ephemeral userids and arrange the dump accordingly, but I think most
> 9grid users would prefer to have at least some permanent resources.
> But maybe that's not even a requirement.  Expiry certainly would be
> nice, specially to prevent denials of service.  I guess the problem is
> not a new one.

I was not suggesting they be ephemeral.  I just was suggesting
that the behavior be that in the absence of evidence to the 
contrary, the user name foo maps to the disk uid foo.

Russ

Re: [9fans] 9grid.us

[Russ Cox]

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

Creating users on the fly would probably be fine for cases
like these.  There is still a translation table from unames to
disk uids so that if there's a user "boyd" and he leaves and
someone else comes along and wants to be user "boyd",
we can assign the new user "boyd" a different disk uid (like
"boyd2") so that we can reuse the uname "boyd" but new
boyd can't read old boyd's files from the dump.  For something
like a 9grid, maybe you're willing to give that up in order to
avoid creating accounts explicitly.

It's not much code, it would be contained in /sys/src/cmd/fossil/9user.c,
but you'd have to fiddle a little with the locking, probably vtRUnlock
inside _userByUname, vtLock, create the new user, vtUnlock, and
then vtRLock again.  Probably pull out the cmdUname user create
code into its own function so that you can reuse it.

Russ

P.S. The type of utility used on sources is not much more than
two tin cans and a piece of string.

Re: [9fans] 9grid.us

[Lucio De Re]

> 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

Re: [9fans] 9grid.us

[Russ Cox]

> > The difference is that standalone doesn't authenticate to
> > its own file server.  The file server trusts the local connection
> > in order to bootstrap.
> 
> The file server means fossil alone?  Or does it include ken fs
> and/or kfs?  Could you give me any pointers to the source where
> this separation occurs?

Both fossil and kfs have provisions for not requiring the
local cpu or terminal kernel to authenticate.  /sys/src/fs
does not, because /sys/src/fs cannot run on the same
machine as one of its clients.

In fossil, the setup is by convention: the config sets up
/srv/fossil using -A to tell it not to require authentication.
In kfs the setup is hard-wired into the code, but the effect
is the same: connections via /srv/boot do not require
authentication.  In both cases, the local kernel is the only
client, and it is assumed to be authenticating its clients
already, so fossil/kfs believes it.

> > You need to add a factotum key for the file server.
> 
> Supposing the following case, what key should I add to which factoum?
> Now a fileserver (fossil) has one (and only one) key:
> 
>         user=sauron dom=tip9ug.jp
> 
> and a diskless cpu server which boots from the
> fileserver has the two keys respectively in their factotums:
> 
>         user=sauron dom=tip9ug.jp
>         user=grid dom=9grid.jp
> 
> Now, one can login to the cpu server using either of the following keys:
>         user=nashi dom=9grid.jp
>         user=nashi dom=tip9ug.jp

So far so good.  If you wanted to disallow using the tip9ug.jp
key to cpu into the cpu server, you could use "user=sauron
dom=tip9ug.jp role=client" as the key in the server factotum.

> However, one can't login with the "user=grid dom=9grid.jp" key.
> Using this key, cpu just finishes without any error message;
>         term% cpu -h cpuserver
>         term%     <-- cpu just exits
> except the "prompt: attach main as grid: unknown user 'grid'"
> on the fossil console.
> 
> The only difference between nashi and grid is that nashi is
> registered to the fossil while grid is not.

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.

Russ

Re: [9fans] 9grid.us

[YAMANASHI Takeshi]

> The difference is that standalone doesn't authenticate to
> its own file server.  The file server trusts the local connection
> in order to bootstrap.

The file server means fossil alone?  Or does it include ken fs
and/or kfs?  Could you give me any pointers to the source where
this separation occurs?

> You need to add a factotum key for the file server.

Supposing the following case, what key should I add to which factoum?
Now a fileserver (fossil) has one (and only one) key:

	user=sauron dom=tip9ug.jp

and a diskless cpu server which boots from the
fileserver has the two keys respectively in their factotums:

	user=sauron dom=tip9ug.jp
	user=grid dom=9grid.jp

Now, one can login to the cpu server using either of the following keys:
	user=nashi dom=9grid.jp
	user=nashi dom=tip9ug.jp

However, one can't login with the "user=grid dom=9grid.jp" key.
Using this key, cpu just finishes without any error message;
	term% cpu -h cpuserver
	term%     <-- cpu just exits
except the "prompt: attach main as grid: unknown user 'grid'"
on the fossil console.

The only difference between nashi and grid is that nashi is
registered to the fossil while grid is not.
-- 

Re: [9fans] 9grid.us

[Eric Van Hensbergen]

On 5/24/05, YAMANASHI Takeshi <9.nashi@gmail.com> wrote:
> > That was basically what I ended up doing (IIRC) was running factotum
> > -Sk and then feeding it my sources account as authid, the
> > outside.plan9.bell-labs.com authdom, a secret secstore key and my
> > sources password.
> 
> So, the only key the factotum(*) has is your sources' key?
> (*) The factotum which is started by the kernel and used by
> cpu service for authentication.
> --

I believe that is correct, yes.  Russ said what was important was that
it be the first key.

      -Eric

Re: [9fans] 9grid.us

[YAMANASHI Takeshi]

> That was basically what I ended up doing (IIRC) was running factotum
> -Sk and then feeding it my sources account as authid, the
> outside.plan9.bell-labs.com authdom, a secret secstore key and my
> sources password.

So, the only key the factotum(*) has is your sources' key?
(*) The factotum which is started by the kernel and used by
cpu service for authentication.
-- 

Re: [9fans] 9grid.us

[Eric Van Hensbergen]

On 5/23/05, YAMANASHI Takeshi <9.nashi@gmail.com> wrote:
> Hi, ericvh, it's great that bringing up 9grid.us like this!
> 
> > > All you need to do is put a sources key (any account)
> > > into your server's factotum.
>  :
> > Worked like a charm - thanks Russ.
> 
> You seem to boot the cpu server under dom=outside.plan9.bell-labs.com
> using your username as hostowner.  Is this correct?
> 

That was basically what I ended up doing (IIRC) was running factotum
-Sk and then feeding it my sources account as authid, the
outside.plan9.bell-labs.com authdom, a secret secstore key and my
sources password.

Made sure I had:

auth=sources.cs.bell-labs.com authdom=outside.plan9.bell-labs.com

in my /lib/ndb/local file.

Rebooted and it just seemed to work. 

         -eric

Re: [9fans] 9grid.us

[Richard Miller]

> So, for folks who didn't see it on IRC: 9grid.us is open for business,
> all you need is a sources account and you should be able to drawterm
> into it.

Or you can connect with cpu(1) - I just tried and it works.

-- Richard

Re: [9fans] 9grid.us

[Eric Van Hensbergen]

On 5/22/05, Russ Cox <russcox@gmail.com> wrote:
> 
> All you need to do is put a sources key (any account)
> into your server's factotum.  
>

Worked like a charm - thanks Russ.

So, for folks who didn't see it on IRC: 9grid.us is open for business,
all you need is a sources account and you should be able to drawterm
into it.  I need to get around to fixing a few things up, but feel
free to drawterm in and check it out.

I'll post more about what I'm thinking about using it for once I set
the webserver/wiki up.

       -eric

Re: [9fans] 9grid.us

[Russ Cox]

> So I've got 9grid.us (with two rather slow cpu servers) more or less
> ready to go.  I wanted to set them up to just use
> sources.cs.bell-labs.com as their authentication server (so anyone
> would a sources account could drawterm to my cpu servers (or mount
> their filesystems, etc.)
> 
> Unfortunately, I'm painfully ignorant about the Plan 9 security model.
>  IRC chatter indicates I need sources.cs.bell-labs.com's hostkey in my
> nvram in order for this to work.

All you need to do is put a sources key (any account)
into your server's factotum.  Unless it says "role=client"
factotum will use it for the server side of authentication.
If you make it the first (or only) such p9sk1 key in the list
then its domain will be the default chosen by a p9any
client with no keys, and thus will be the domain prompted
with when clients connect.

Russ

[9fans] 9grid.us

[Eric Van Hensbergen]

So I've got 9grid.us (with two rather slow cpu servers) more or less
ready to go.  I wanted to set them up to just use
sources.cs.bell-labs.com as their authentication server (so anyone
would a sources account could drawterm to my cpu servers (or mount
their filesystems, etc.)

Unfortunately, I'm painfully ignorant about the Plan 9 security model.
 IRC chatter indicates I need sources.cs.bell-labs.com's hostkey in my
nvram in order for this to work.

Suggestions?

               -eric