Re: [9fans] Attach/Auth

Re: [9fans] Attach/Auth

[Russ Cox]

That's my fault.

    case Tauth:
	if((r->fid = allocfid(srv->fpool, r->ifcall.fid)) == nil){
		respond(r, Edupfid);
		break;
	}
	r->afid = nil;
	if(r->ifcall.afid != NOFID && (r->afid = allocfid(srv->fpool, r->ifcall.fid)) == nil){
		respond(r, Eunknownfid);
		break;
	}

The line in question should actually be

	if(r->ifcall.afid != NOFID && (r->afid = allocfid(srv->fpool, r->ifcall.afid)) == nil){

Note the s/fid/afid/ near the end of the line.
Goes to show that we've never actually used authentication, I suppose.

Russ

Re: [9fans] Attach/Auth

[Lucio De Re]

On Tue, Aug 27, 2002 at 07:25:50AM -0400, Russ Cox wrote:
>
>     case Tauth:
> 	if((r->fid = allocfid(srv->fpool, r->ifcall.fid)) == nil){
> 		respond(r, Edupfid);
> 		break;
> 	}
> 	r->afid = nil;
> 	if(r->ifcall.afid != NOFID && (r->afid = allocfid(srv->fpool, r->ifcall.fid)) == nil){
> 		respond(r, Eunknownfid);
> 		break;
> 	}
>
> The line in question should actually be
>
> 	if(r->ifcall.afid != NOFID && (r->afid = allocfid(srv->fpool, r->ifcall.afid)) == nil){
>
> Note the s/fid/afid/ near the end of the line.

Hm.  I replaced the allocfid() with lookupfid(), plus the change you
mentioned, because afid is already allocated in Tauth (did I really
put Tauth up there?  I meant Tattach!).

> Goes to show that we've never actually used authentication, I suppose.
>
That's perfectly reasonable, as long as somebody eventually irons out
the creases :-)

++L

Re: [9fans] Attach/Auth

[Alexander Viro]

On Thu, 29 Aug 2002, Russ Cox wrote:

> Oh, you mean the section 5 man pages rather than
> the lib9p man pages.  Ephase is a property of the
> implementation, which can do whatever it pleases.
> There can be file servers that will never give
> you Ephase (like u9fs running on a typical Unix
> file system).

I suspect that Roman was looking at the manpages in question from
the different side - he's dealing with client, not the servers.
So it's not a matter of "you are not required to...", but "you should
not expect the other side to...".

Re: [9fans] Attach/Auth

[Roman V. Shaposhnick]

That's exactly why I'm asking to mention that fids are no guarantee for
resource being available -- it's entirely up to the server and client
can make no assumptions whatsoever.

Well, it would've saved me 1.5 days :( Anyway, if you consider this to be
a minor issue -- let's just forget about it.

Thanks,
Roman.

On Thu, Aug 29, 2002 at 11:10:41PM -0400, Russ Cox wrote:
> Oh, you mean the section 5 man pages rather than
> the lib9p man pages.  Ephase is a property of the
> implementation, which can do whatever it pleases.
> There can be file servers that will never give
> you Ephase (like u9fs running on a typical Unix
> file system).
>
> Russ

Re: [9fans] Attach/Auth

[Russ Cox]

Oh, you mean the section 5 man pages rather than
the lib9p man pages.  Ephase is a property of the
implementation, which can do whatever it pleases.
There can be file servers that will never give
you Ephase (like u9fs running on a typical Unix
file system).

Russ

Re: [9fans] Attach/Auth

[Roman V. Shaposhnick]

On Wed, Aug 28, 2002 at 06:45:02AM -0400, Russ Cox wrote:
> >   Russ, can you also add something to the effect of "fids can be dangling"
> >   to the 9P manpages ? May be I'm being too picky, but I have a good reason --
> >   I've learned that in a pretty hard way.
>
> what forsyth said.  also, fids can dangle in the sense that if you
> don't take care of closing all of them, there will just be
> garbage in memory but the fid table bookkeeping stays correct.
> i hope that's not what you mean, though.

  You're right. That's not what I meant.

> can you rephrase that?

  Sure. I just asked to mention that fid doesn't guarantee you that resource
  it points to will be available for the next operation. You may get Ephase.
  The reason I was asking to add this to the 9P manpages is that fids are
  very similar to object handles and most of the time people expect handles
  to stay valid until explicitly released ( clunked ).

Thanks,
Roman.

Re: [9fans] Attach/Auth

[Russ Cox]

>   Russ, can you also add something to the effect of "fids can be dangling"
>   to the 9P manpages ? May be I'm being too picky, but I have a good reason --
>   I've learned that in a pretty hard way.

what forsyth said.  also, fids can dangle in the sense that if you
don't take care of closing all of them, there will just be
garbage in memory but the fid table bookkeeping stays correct.
i hope that's not what you mean, though.

can you rephrase that?

Re: [9fans] Attach/Auth

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 389 bytes --]

but fids can't be `dangling'.  they're allocated by one request or another (eg, Tattach, Tauth, Twalk),
and deallocated by Tclunk or Tremove.  they can't `dangle'.
if the client has allocated a fid, it is valid until it explicitly deallocates it.
if the client hasn't allocated a fid but uses it in a request,
it's a protocol error by the client (eg, `fid in use', or `unknown fid').

[-- Attachment #2: Type: message/rfc822, Size: 2020 bytes --]

From: "Roman V. Shaposhnick" <vugluskr@unicorn.math.spbu.ru>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Attach/Auth
Date: Wed, 28 Aug 2002 10:15:31 +0400
Message-ID: <20020828101531.A3072@unicorn.math.spbu.ru>

On Tue, Aug 27, 2002 at 08:25:49AM -0400, Russ Cox wrote:
>
> Anyhow, I just fixed the various bugs you pointed out in the manual pages.
> Let me know about any incompletenesses.

  Russ, can you also add something to the effect of "fids can be dangling"
  to the 9P manpages ? May be I'm being too picky, but I have a good reason --
  I've learned that in a pretty hard way.

Thanks,
Roman.

Re: [9fans] Attach/Auth

[Roman V. Shaposhnick]

On Tue, Aug 27, 2002 at 08:25:49AM -0400, Russ Cox wrote:
>
> Anyhow, I just fixed the various bugs you pointed out in the manual pages.
> Let me know about any incompletenesses.

  Russ, can you also add something to the effect of "fids can be dangling"
  to the 9P manpages ? May be I'm being too picky, but I have a good reason --
  I've learned that in a pretty hard way.

Thanks,
Roman.

Re: [9fans] Attach/Auth

[Russ Cox]

> Hm.  I replaced the allocfid() with lookupfid(), plus the change you
> mentioned, because afid is already allocated in Tauth (did I really
> put Tauth up there?  I meant Tattach!).

Oh, right.  Fixed.

> > Goes to show that we've never actually used authentication, I suppose.

> That's perfectly reasonable, as long as somebody eventually irons out
> the creases :-)

The reason that we've never actually used authentication is that most
user-level file servers don't need to authenticate.  They post files
that are mode 0600 in srv (or don't post at all) and mount into the
namespace directly.  Thus, by default the kernel will make sure that
only you can get at the file server.  You don't need to protect it
further.  Kfs only needs to deal with authentication because it can
listen to the network, speaking 9P with arbitrary clients rather than
just with the kernel.  For what you're doing, it doesn't sound like you
need authentication.

It also sounds like you should just use upas/fs.  Given a message you
can just do:

	{
		echo 'From xxx' `{date}
		sed '/^$/,$ s/^From / From /'
		echo
	} >$TMP
	upas/fs -f $TMP

Anyhow, I just fixed the various bugs you pointed out in the manual pages.
Let me know about any incompletenesses.

Of course, it's impossible to write documentation without noticing
unnecessary complications in the implementation, so the library itself
has been slightly stirred around as well, to be easier to explain.
No programs should need to change unless they're relying on very subtle
implementation details (and even I don't have such programs).

/sys/src/lib9p/ramfs.c is now in the distribution.  Sorry about forgetting
it earlier.

Russ

Re: [9fans] Attach/Auth

[Lucio De Re]

On Tue, Aug 27, 2002 at 07:06:23AM +0200, Lucio De Re wrote:
>
> which is followed by a puzzling Tattach exchange:
>
> 	<-4- Tattach tag 13 fid 349 afid 333 uname lucio aname
> 	-4-> Rerror tag 13 ename unknown fid
>
> I assume the "unknown fid" comes from srv() which I don't quite
> understand.
>
The following code in /sys/src/lib9p/srv.c is suspicious:

    case Tauth:
	if((r->fid = allocfid(srv->fpool, r->ifcall.fid)) == nil){
		respond(r, Edupfid);
		break;
	}
	r->afid = nil;
	if(r->ifcall.afid != NOFID && (r->afid = allocfid(srv->fpool, r->ifcall.fid)) == nil){
		respond(r, Eunknownfid);
		break;
	}

The second allocfid() seems to work a lot better if replaced by:

	lookupfid(srv->fpool, r->ifcall.afid)

The Tattach exchange now looks like:

	<-4- Tattach tag 11 fid 324 afid 339 uname lucio aname
	-4-> Rattach tag 11 qid (0000000000000000 0 d)

which seems a little healthier except for the Qid value, which
repeats the value that was assigned to the auth file.

++L

Re: [9fans] Attach/Auth

[Lucio De Re]

On Mon, Aug 26, 2002 at 07:24:39PM -0400, Russ Cox wrote:
>
> The afd used in the attach message is the
> one returned by a Tauth/Rauth exchange.
> If Tauth returns an error then afd = -1 gets used.
> The attach spec should be irrelevant, unless
> the server in question (what is it?) behaves
> differently on Tauth to nil and Tauth to /mail/box/lucio/mbox.
>
The server I'm trying to construct, painfully, is a variation on
upas/fs that handles a single Mime document rather than an entire
mailbox.

It's part of a much bigger project I won't bore anyone with just
yet but a very fundamental portion of it.

So far I have managed to install the server on /srv so that it
reacts to a "mount /srv/sample /n/temp" and even reports receiving
Tread messages on "afid".  But the details are terribly blurry.

I can't find an example that covers all the aspects I want.  The
idea is to run mime/fs analogously to dossrv or 9660srv, then mount
a particular document onto a chosen destination:

	% mime/fs -R -p sample
	8.sample 463: serving sample
	% mount /srv/sample /mime/3 /mail/msg/3

The -R option on mime/fs would inhibit descending the Mime hierarchy,
essential if one uses Mime (Boyd, I know I'm looking for trouble,
I'll rethink the whole thing once the experimental phase is over)
as the containing folder and one does not want upas/fs's hunger
for memory.

What I'm trying to understand is how to tie auth_proxy(2) into the
Tauth routine for srv(2).  I get the Auth message from

	% mount /srv/sample /n/temp

	<-4- Tauth tag 13 fid 333 uname lucio aname
	-4-> Rauth tag 13 qid (0000000000000000 0 A)

from a somewhat confused auth() function.  Nowhere in the documentation
I have, is it explained what's _really_ meant to happen next.  I
believe I ought to return req->ofcall->aqid and a nil error message,
which I do (the qid turns out to be zero, which I find a bit
bothersome, but, if I read the above correctly, at least has the
QTAUTH flag set)

I presume I have to record somewhere the afid as the authentication
fid for this session which leads me to ask two questions: (1) do
I need to keep the afid for each connection to the server and how
best do I do this? and (b) how do I relate this fid to an authentication
channel:  can I somehow proxy or delegate a factotum connection
over it, or do I have to reroute factotum RPC requests individually?

I note that the next transaction (my server does nothing more than
report incoming messages past this stage) is an empty Tread:

	<-4- Tread tag 13 fid 333 offset 0 count 2048

(oops, that's not empty - it used to be, but that was before I
stumbled into QTAUTH) over afid, which gets a reply from my empty
read() function:

	-4-> Rread tag 13 count 0 ''

which is followed by a puzzling Tattach exchange:

	<-4- Tattach tag 13 fid 349 afid 333 uname lucio aname
	-4-> Rerror tag 13 ename unknown fid

I assume the "unknown fid" comes from srv() which I don't quite
understand.

I'll happily publish the source for this exercise once it can serve
as a working example, in the meantime I guess I must supplement
the documentation with details derived from trial and error.

One last question.  In the Plan 9 Security Paper, mention is made
that "When client and server have successfully negotiated, the
authentication file changes state so it can be used as evidence of
authority in mount".  I would like to know how it changes state
and whether the server is responsible for this state change.

I have looked carefully at 9p2.c in the KFS sources, where the
factotum/rpc dialogue is re-routed and, apparently, the server
stands aside until it's complete, but I don't understand how to
duplicate this in a user level server (I think my understanding of
Plan 9 file services, fids and qids is severly lacking) and I
sometimes begin to think that removing authentication from servers
is a chimera that has not been achieved yet.

++L

Re: [9fans] Attach/Auth

[Russ Cox]

The afd used in the attach message is the
one returned by a Tauth/Rauth exchange.
If Tauth returns an error then afd = -1 gets used.
The attach spec should be irrelevant, unless
the server in question (what is it?) behaves
differently on Tauth to nil and Tauth to /mail/box/lucio/mbox.

Russ

[9fans] Attach/Auth

[Lucio De Re]

Given a test server, I get the expected authentication request:

	% mount /srv/sample /n/temp

which fails because I have no idea (yet) quite what to do next.
But my lack of understanding is not mysterious :-)

On the other hand:

	% mount /srv/sample /n/temp /mail/box/lucio/mbox

does not request authentication, it uses an afd of -1 in an attach
message.

I can't see a good reason for this, but I'm sure there is one I'm
missing, could someone please shed some light?

++L

PS: the whole exercise is quite exciting, just very slow progress.