9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] 9grid
@ 2008-11-14 12:23 erik quanstrom
  2008-11-14 15:10 ` lupin636
  2008-11-17 10:12 ` lupin636
  0 siblings, 2 replies; 48+ messages in thread
From: erik quanstrom @ 2008-11-14 12:23 UTC (permalink / raw)
  To: lupin636, 9fans

> Hi,
> I just did it:
>    fsname%  ndb/query -f /lib/ndb/auth hostid bootes
>    fsname%
> i got no response,only the fs prompt..
> but in /lib/ndb/auth.mio i have the same lines,so:
>    hostid°otes
>         uid
> dm uid
> ??

easy fix
	9fs sources && cp /n/sources/plan9/lib/ndb/auth /lib/ndb/auth

- erik



^ permalink raw reply	[flat|nested] 48+ messages in thread
* Re: [9fans] 9grid
@ 2008-11-17 14:14 erik quanstrom
  2008-11-17 16:22 ` lupin636
  0 siblings, 1 reply; 48+ messages in thread
From: erik quanstrom @ 2008-11-17 14:14 UTC (permalink / raw)
  To: lupin636, 9fans

On Mon Nov 17 09:17:49 EST 2008, lupin636@gmail.com wrote:
> Hi Eric, (sic)
> I did what you told me, and i got the same as you wrote below.
> if you still have any idea, it will be helpful.
> thanks again,

you need to verify the keys also match.

- erik



^ permalink raw reply	[flat|nested] 48+ messages in thread
* Re: [9fans] 9grid
@ 2008-11-13 15:43 erik quanstrom
  2008-11-13 17:06 ` lupin636
  2008-11-14  9:44 ` torsbohn
  0 siblings, 2 replies; 48+ messages in thread
From: erik quanstrom @ 2008-11-13 15:43 UTC (permalink / raw)
  To: lupin636, 9fans

> I did it and it works, but do you have any idea why i can do it from
> file server as bootes but not from terminal as armando?

there's probablly something wrong in your authentication setup.

>      fs name% cpu -h NODE -c 'name=(equal sign)cat ''#c/sysname'';
> echo'

cpu -h node -c 'name=`{cat ''#c/sysname''}; echo do something with $name'

- erik



^ permalink raw reply	[flat|nested] 48+ messages in thread
* Re: [9fans] 9grid
@ 2008-11-11 12:09 erik quanstrom
  2008-11-11 13:18 ` lupin636
  0 siblings, 1 reply; 48+ messages in thread
From: erik quanstrom @ 2008-11-11 12:09 UTC (permalink / raw)
  To: lupin636, 9fans

> Hi Eric,
> I check lib/ndb/auth in the file server, this is what i have:
>     hostid°otes
>             uid
> dm uid

i assume poor spelling and cut-n-paste failure. :-)
the key thing here is if the only hostid in /lib/ndb/auth
is bootes, then the cpu server's hostowner must be
bootes.  is it?  can you run commands from the cpu
server's console?

you're doing the right thing, you've just got a
configuration error.

- erik



^ permalink raw reply	[flat|nested] 48+ messages in thread
* Re: [9fans] 9grid
@ 2008-11-10 18:38 erik quanstrom
  2008-11-11  9:50 ` lupin636
  0 siblings, 1 reply; 48+ messages in thread
From: erik quanstrom @ 2008-11-10 18:38 UTC (permalink / raw)
  To: lupin636, 9fans

> I have a doubt.....because i was thinking about all i have to do, and
> i don't know if using cpu command is the right thing to do. anyway,
> the fact is, i have to launch a simple task from terminal (connected
> by armando) to a node on the cluster (diskless cpu server), i thought
> that cpu command was right but i'm not really sure anymore, because in
> unix i used to use "rsh" and "rcmd".
> any suggestions please??

you've got some sort of problem starting a shell on the remote machine.
it's likely authentication.  make sure the hostowner has speaksfor
abilities on the auth server (/lib/ndb/auth).

- erik



^ permalink raw reply	[flat|nested] 48+ messages in thread
* Re: [9fans] 9grid
@ 2008-11-10 11:35 erik quanstrom
  2008-11-10 14:13 ` lupin636
  2008-11-10 17:35 ` lupin636
  0 siblings, 2 replies; 48+ messages in thread
From: erik quanstrom @ 2008-11-10 11:35 UTC (permalink / raw)
  To: lupin636, 9fans

> trying with cpu(1) command, i was doing:
>     cpu -h fileservername
> and the prompt changed from term% to cpu%, and i supposed that was
> correct, but when i tried to connect to a cpuserver (all nodes are
> diskless)
>     cpu -h cpuservername
> the prompt didn't change, is that correct? before doing this, i tried
> with

there's nothing in the system itself that changes one's prompt.
this is done by the profile.  typically one can use the convention
that $sysname is the contents of /dev/sysname.
; echo $sysname $cpu
brasstown ladd
; cpu
; echo $sysname

- erik



^ permalink raw reply	[flat|nested] 48+ messages in thread
* [9fans] 9grid
@ 2008-11-10  9:56 lupin636
  0 siblings, 0 replies; 48+ messages in thread
From: lupin636 @ 2008-11-10  9:56 UTC (permalink / raw)
  To: 9fans

Hi All,
I'm accomplishing a 9grid, that is composed of a file server, 2
cluster (diskless cpuserver nodes) and a terminal..
I'm trying to connect to a cpuserver (node of 9grid) from a terminal,
to launch some tasks, but i don't really know how to do it, i was
trying with cpu(1) command, i was doing:
    cpu -h fileservername
and the prompt changed from term% to cpu%, and i supposed that was
correct, but when i tried to connect to a cpuserver (all nodes are
diskless)
    cpu -h cpuservername
the prompt didn't change, is that correct? before doing this, i tried
with
    cpu -h cpuservername -c cmd args
but i'm not really sure if the replay i obtained was neither from that
cpuserver or from terminal.
All of this, i was trying to do to testing nodes, in effect, i'd want
to launch from terminal a simple program i.e.: i say "hello" and the
chosen node replays "hasta la vista baby".
Thanks in advance for every response.

Armando.



^ permalink raw reply	[flat|nested] 48+ messages in thread
* Re: [9fans] 9grid
@ 2005-06-09  2:17 YAMANASHI Takeshi
  2005-06-09  2:28 ` andrey mirtchovski
  0 siblings, 1 reply; 48+ messages in thread
From: YAMANASHI Takeshi @ 2005-06-09  2:17 UTC (permalink / raw)
  To: 9fans

On Thu Jun  9 10:42:09 JST 2005, andrey mirtchovski wrote:
> > I wonder how globus is managing these issues...
> 
> globus leaves trust relationships to the certificate authorities which
> create accounts and issue CN's (callnames) for grid users.

What about other issues like posting spam and organising DDos attack?
-- 




^ permalink raw reply	[flat|nested] 48+ messages in thread
* Re: [9fans] 9grid
@ 2005-06-09  1:41 andrey mirtchovski
  0 siblings, 0 replies; 48+ messages in thread
From: andrey mirtchovski @ 2005-06-09  1:41 UTC (permalink / raw)
  To: 9fans

> I wonder how globus is managing these issues...

globus leaves trust relationships to the certificate authorities which
create accounts and issue CN's (callnames) for grid users.

CN's which have access to a particular machine are listed in a grid
mapfile on each machine of the grid.

this isn't the only way to do it, but is the most common.

here's me on westgrid (edited slightly):

"/C=CA/O=Grid/OU=westgrid.ca/CN=andrey mirtchovski_46/Email=mirtchov cpsc ucalgary ca" andrey

the CN's are not secret.



^ permalink raw reply	[flat|nested] 48+ messages in thread
* Re: [9fans] 9grid
@ 2005-06-09  1:27 YAMANASHI Takeshi
  2005-06-09  3:01 ` Ronald G. Minnich
  0 siblings, 1 reply; 48+ messages in thread
From: YAMANASHI Takeshi @ 2005-06-09  1:27 UTC (permalink / raw)
  To: 9fans

> The single central auth server approach uses the
> outside.plan9.bell-labs.com auth server allowing anyone who has
> a sources account (I.E. anyone who wants to), to attach to grid nodes

Yes.  But that's not the problem both multi authdom proposals are
trying to solve, I guess.  If you don't like the way sources accounts are
distributed (I.E. anyone who wants to), you can choose not to trust
the sources auth server and use others instead, like 9grid.de and/or tip9ug.
Both proposals are allowing you which authdom you trust or not.
Also, both proposals solved the username crash between multiple
authdoms.

Oh wait, what's the difference between the two proposals, btw?

> and run arbitary software, and read any world readable files
> on any node.

These are next hurdles I would like to jump over.
How about constructing the namespace of a grid user
only from /mnt/term/* ?

> how can an adminstrator on one side of the world trust an unknwon
> user on the other side?

Maybe he can't confidently trust unknown users in an authdom
on the other side of the world, but he may trust the admin of
the authdom reasonably.  I think this is the heart of grid's
authentication in general.


> Unfortunately in the current implementation, exchanges between the auth
> servers rely on DNS for mutual authentication.

I'm sorry.  I'm left behind here.  Which parts of the current
implementation rely on DNS for mutual authentication?


> Next we need some way to stop grid users hogging too much of a nodes
> cpu capacity, network bandwidth, disk space, and to stop them posting spam
> or organising DDoS attacks...

I wonder how globus is managing these issues...
-- 




^ permalink raw reply	[flat|nested] 48+ messages in thread
* [9fans] 9grid
@ 2005-06-08 14:14 Steve Simon
  2005-06-08 15:16 ` Russ Cox
  2005-06-08 20:55 ` arisawa
  0 siblings, 2 replies; 48+ messages in thread
From: Steve Simon @ 2005-06-08 14:14 UTC (permalink / raw)
  To: 9fans

Hi,

First I wish to apologise as this will offend some people.

Am I the only one who is horrorfied at the lack of security
implied by the two recent cross domain authentication proposals?
I applaud any well written code for plan9 but I don't feel either
are ready for production.

The single central auth server approach uses the
outside.plan9.bell-labs.com auth server allowing anyone who has
a sources account (I.E. anyone who wants to), to attach to grid nodes
and run arbitary software, and read any world readable files
on any node. Ok Plan9 is more secure than some OS's but I wouldn't
allow just _anyone_ access to my machine.

There is no trust relationship with the users. Even if accounts where
explicitly enabled on demand and not by default there is still the problem
of how can an adminstrator on one side of the world trust an unknwon
user on the other side?

The system that delegates authentication to remote, trusted servers
requires the node adminstartor to explicitly set up this trust relationship
so there is much more control here. The adminstrator of each remote authdom
retains responsibility for the actions of their users on remote hosts,
thus we have a distributed system of trust; users would connect to their local
grid node to access the grid as whole, at least here we have a chance that
the adminstartors may know and trust their users who they allow onto the grid.

Unfortunately in the current implementation, exchanges between the auth
servers rely on DNS for mutual authentication. Given knowledge of a valid peer
node's domain name DNS poisining atttacks could easily allow a malacious user
access to all grid node; The once secure Plan9 OS is now wide open.

I can think of only two other possible structures for the grid.

1/ Shared private keys between N grid node's auth servers, these secrets
are used to ensure mutual authentication between auth servers and would
prevent the DNS posioning attack above. Unfortunately this would need 2N
secrets which must be securely distributed.

2/ Public Key encryption to secure the channel between auth servers. This
would need only N public keys, which could be distributed in the clear;
A central Certification Authority would not be needed as plan9 already has
a distributed file system, the certificates _are_ files.

Russ sugested that the certificates could have timestamps allowing remote
users to be proxy authenticated by a local auth server until an expiry timeout
has been reached, at which point an authoratitive certificate would have to be
fetched. This would be a very significant win over long-hall networks.

The solution to 9grid authentication seems clear to me.

Next we need some way to stop grid users hogging too much of a nodes
cpu capacity, network bandwidth, disk space, and to stop them posting spam
or organising DDoS attacks...

-Steve


^ permalink raw reply	[flat|nested] 48+ messages in thread

end of thread, other threads:[~2008-11-17 16:22 UTC | newest]

Thread overview: 48+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-11-14 12:23 [9fans] 9grid erik quanstrom
2008-11-14 15:10 ` lupin636
2008-11-17 10:12 ` lupin636
2008-11-17 11:54   ` erik quanstrom
2008-11-17 14:13   ` lupin636
  -- strict thread matches above, loose matches on Subject: below --
2008-11-17 14:14 erik quanstrom
2008-11-17 16:22 ` lupin636
2008-11-13 15:43 erik quanstrom
2008-11-13 17:06 ` lupin636
2008-11-13 17:24   ` andrey mirtchovski
2008-11-13 17:26     ` erik quanstrom
2008-11-14  9:44     ` lupin636
2008-11-14  9:44 ` torsbohn
2008-11-14 13:53   ` erik quanstrom
2008-11-11 12:09 erik quanstrom
2008-11-11 13:18 ` lupin636
2008-11-11 14:42   ` john
2008-11-11 15:12   ` lupin636
2008-11-11 15:40     ` Uriel
2008-11-11 16:32     ` lupin636
2008-11-11 17:14       ` Uriel
2008-11-12  0:13     ` ron minnich
2008-11-12  0:11       ` erik quanstrom
2008-11-12  0:41         ` ron minnich
2008-11-12  0:36           ` erik quanstrom
2008-11-12  0:59             ` ron minnich
2008-11-12 10:27     ` lupin636
2008-11-12 14:38       ` john
2008-11-12 16:16       ` lupin636
2008-11-13 12:08       ` lupin636
2008-11-13 12:28         ` erik quanstrom
2008-11-13 15:32         ` lupin636
2008-11-10 18:38 erik quanstrom
2008-11-11  9:50 ` lupin636
2008-11-10 11:35 erik quanstrom
2008-11-10 14:13 ` lupin636
2008-11-10 17:35 ` lupin636
2008-11-10 17:46   ` ron minnich
2008-11-11  9:50   ` lupin636
2008-11-10  9:56 lupin636
2005-06-09  2:17 YAMANASHI Takeshi
2005-06-09  2:28 ` andrey mirtchovski
2005-06-09  1:41 andrey mirtchovski
2005-06-09  1:27 YAMANASHI Takeshi
2005-06-09  3:01 ` Ronald G. Minnich
2005-06-08 14:14 Steve Simon
2005-06-08 15:16 ` Russ Cox
2005-06-08 20:55 ` arisawa

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