Re: [9fans] u9fs

["Russ Cox" <rsc@plan9.bell-labs.com>]

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

Not exactly true.  Factotum uses the first one it finds.

If I wanted to use a different key I could use, for example,

	mount -k 'user=glenda' /srv/sources /n/sources
	cpu -k 'user=glenda' -h sources

to select a key.  Of course, the fact that I'm selecting
on the user attribute is not why this works.  I could select
on any attribute in the key, and then that key (with its
user name) will be used.

This works really well when there are keys.  When there
are not keys, it's harder because there are no Tauth messages
in which to pass remote user names.  We could invent
a `unix' protocol consisting of sending a uid, but there's
no authentication in that. 

The ssh user@host syntax is annoying but standard
in the SSH world.  It is also somewhat necessary given
how SSH chooses to run its authentication:
you declare user up front, and then try a whole bunch
of authentication methods.  You can't change your 
user name after one fails.

As for ~/.u9fs or uid mappings on the server, there's
really little point.  If you're using .rhosts authentication,
then there's nothing stopping me from making my own
connection to the u9fs service (with aux/9pcon or more
usefully with a 9P filter in front of the kernel) and sending
whatever attach name I want.  There's no authentication
here, and I don't want to start pretending there is.
It is worth noting, though, that if your Plan 9 system is not listed
in /etc/rhosts.equiv, then users can opt in or out by editing
their .rhosts files already.  So you really don't need a .u9fs file.

Russ