9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] u9fs
Date: Fri, 31 Jan 2003 16:35:54 +0100	[thread overview]
Message-ID: <200301311535.h0VFZsY04092@zamenhof.cs.utwente.nl> (raw)
In-Reply-To: Your message of "Tue, 28 Jan 2003 10:50:03 -0500." <37b786bb09656d2a3ea7cc27a27ad3ea@plan9.bell-labs.com>

> There are changes to u9fs on sources that add support
> for p9any as an authentication protocol.  Thanks to Nigel.


Great! Thanks!



I reintegrated my u9fs modifications mentioned on the list
before (for previous u9fs versions); I (think I) need them
because my plan 9 user list differs from the unix user list,
and these lists are managed by different people.
They consist of a plan9-user to unix-user username mapping
via a mapping file, and a hack to recognize '-lunixuser' in
the attach name as a way to specify the unix-user name.
I think(*) I like this flexibility, as I only use one
plan 9 account but several unix ones.

(*) it is all a bit experimental -- finding out what I want/need;
 right now I even don't rule out the potential conclusion that
 what I'm doing is too much, such that it can be removed again.

My modifications worked nicely in combination with .rhosts
authentication, because then a unix user had to explictly allow
attach from plan 9 as his/her via an entry in .rhosts.

With p9any this `limitation' is no longer there, allowing
in principle to attach as any unix user (except root).
To counter this, I added yet another modification,
which kind of imitates the .rhosts file.
With this modification, attach from plan9 only succeeds
if the plan 9 user name is present in a .u9fs file in
the home dir of the unix user as whom we try to attach.
In particular, this means that to attach as unix user
``A'' it is no longer sufficient to just add a new
user ``A'' on plan 9; user ``A'' on unix must explictly
allow the attach via his .u9fs file.

The code I have just works and still needs cleaning up
(is still full of detailed debugging print statements);
if there is interest I can post or put on the web.



On a related note: I noticed that in the transition
from 3ed to 4ed u9fs lost its -r (readonly) flag;
are there particular reasons for that?

I have been toying with the idea of allowing even greater
control at the unix side, by allowing a ``readonly''
keyword with a user name in the .u9fs file.
Suppose I would like to put readonly access back in,
would it be sufficient to look at 3ed u9fs and ``copy''
from there? Or are there cases that I would miss?

Axel.





  reply	other threads:[~2003-01-31 15:35 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-28 15:50 Russ Cox
2003-01-31 15:35 ` Axel Belinfante [this message]
2003-01-31 16:07   ` Nigel Roles
2003-01-31 16:39     ` Russ Cox
2003-01-31 18:23       ` Axel Belinfante
2003-01-31 18:45         ` Russ Cox
2003-01-31 22:54           ` Axel Belinfante
  -- strict thread matches above, loose matches on Subject: below --
2008-03-30 11:36 arisawa
2008-03-30 12:25 ` arisawa
2003-10-09 14:24 [9fans] U9FS Lucio De Re
2003-02-18 16:38 [9fans] u9fs Ronald G. Minnich
2003-02-18 16:42 ` Russ Cox
2003-02-18 17:12   ` Ronald G. Minnich
2003-02-18 17:18     ` Russ Cox
2003-02-18 16:49 ` nigel
2002-12-09  8:09 Russ Cox
2002-12-09  7:51 YAMANASHI Takeshi
2002-12-05 17:49 David Swasey
2002-05-05 23:24 [9fans] Bug report Russ Cox
2002-05-05 23:33 ` arisawa
2002-05-05 23:39   ` [9fans] u9fs arisawa
2002-03-24  6:42 Russ Cox
2002-03-23 18:45 nigel
2002-03-23 18:12 Russ Cox
2002-03-24  5:44 ` Martin C.Atkins
2002-03-26 10:45 ` Christopher Nielsen
2002-03-23 10:43 nigel
2002-03-22 13:42 Jean Mehat
2002-03-21 16:19 Russ Cox
2002-03-23  0:40 ` Christopher Nielsen
2002-03-20 22:00 forsyth
2002-03-20 19:31 Russ Cox
2002-03-20 19:31 markp
2002-03-20 19:05 Russ Cox
2002-03-20 19:42 ` skipt
2002-03-21 11:02 ` Peter Canning
2002-03-20 18:40 markp
2002-03-20  9:27 Fco.J.Ballesteros
2002-03-20  7:10 Geoff Collyer
2002-03-20  7:23 ` Lucio De Re
2002-03-20  8:10 ` Dean Prichard
2002-03-20  7:01 forsyth
2002-03-20  5:15 Russ Cox
2002-03-19 22:33 Russ Cox
2002-03-19 17:19 Russ Cox
2002-03-19 16:39 forsyth
2002-03-19 16:18 anothy
2002-03-19 16:46 ` Dharani Vilwanathan
2002-03-19 22:00   ` Dharani Vilwanathan
2002-03-19 14:03 [9fans] long long warning nigel
2002-03-19 16:07 ` [9fans] u9fs Dharani Vilwanathan
2002-03-19 16:15   ` William Josephson
2002-03-20  4:46   ` Steve Kotsopoulos
2001-01-07  6:08 rob pike
2001-01-07  5:54 rob pike
2001-01-07  6:00 ` Boyd Roberts
2000-07-07 16:16 ianb
2000-07-07 14:46 Ish Rattan
2000-07-07 15:26 ` Steve Kotsopoulos
1999-04-23 11:05 [9fans] U9FS 
1999-04-22 16:31 Russ
1999-04-22  8:32 
1999-03-18 11:30 Jean
1999-03-17 23:47 Ed
1999-03-17 19:48 Markus
1999-03-17 19:16 Scott
1999-03-17 16:26 
1999-03-17 15:07 

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=200301311535.h0VFZsY04092@zamenhof.cs.utwente.nl \
    --to=axel.belinfante@cs.utwente.nl \
    --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).