From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <200301311823.h0VIN3i04754@zamenhof.cs.utwente.nl>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] u9fs
In-reply-to: Your message of "Fri, 31 Jan 2003 11:39:29 -0500."
             <389f7c6be0fd771d00fd464fe5c95a37@plan9.bell-labs.com> 
References: <389f7c6be0fd771d00fd464fe5c95a37@plan9.bell-labs.com> 
From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 31 Jan 2003 19:23:03 +0100
Topicbox-Message-UUID: 4b013262-eacb-11e9-9e20-41e7f4b1d025

> The new u9fs doesn't have
> a -r flag because we don't use it,
> so I didn't implement it.  Same for
> chroot and some other things that
> have made their way back.

That's the reason I expected. Good.
 
> While I'd be happy to pick up a -r flag, I'm
> hesitant about having a per-directory .u9fs file.

(one per-user (in the user's unix home directory))

>  That seems too specific to your particular case.

Probably it is. One the one hand I like the idea
of giving the unix user a choice; on the other hand,
it's a bit (too?) much.

> I'm torn about the uid mappings.  I feel like
> there should be a more general solution.

That would be great.

> With real authentication, factotum just does
> the right thing.  (For example, I have an account
> called bozo on sources.  I run 9fs sources and it
> automatically uses that name because it's the only
> key I have for the machine.)

... because you have only one account at the machine,
or, at least, only one that is `interesting enough'
to have a key for in factotum.

The nice behaviour in your example immediately
illustrates the disadvantage of my overloading-of-
attach-name hack: you not only can, but also have
to specify the unix user name. If you want to
(be able to) choose, you need (a way) to `voice'
your choice. So, the problem seems to start with
the possibility of having a one-to-many mapping,
because then a choice has to be made, and voiced.

But isn't this problem similar to the problem of
having multiple remote accounts on a single machine,
and then having to choose/identify one of them,
when making a connection to that host (e.g.) via ssh?

In this respect, the idea of the (one-to-one) mapping
file (which, I think, was suggested by Forsyth in an
earlier discussion about u9fs) is better, because it
just specifies a fixed one-to-one (or maybe many-to-one
but not one-to-many) plan9->unix name mapping that is
just slightly different from the also fixed one-to-one
(identity function) plan9->unix name mapping in the
unmodified u9fs. You just have one name at the unix
system (either identical to your plan 9 name, or
different  from it, but then automated via the
mapping file so it is out of your hands anyway),
which allows the same automation as in your example.

W.r.t. ~/.u9fs files:
If you don't have the general flexible -lunixuser
attach name hack (and you trust the maintainer of
the mapping file if it's there), and you trust your
plan 9 administrator not to add plan 9 users just
to get at unix files, there probably is no need for
the ~/.u9fs files.

> When there's no authentication, it's a little harder.
> I'm having the same problem with an NFS client I'm
> writing.  I'm not sure what to do.

Axel. (who wonders when he will learn to write concisely)