From: Neil Brown (neilb@cse.unsw.edu.au)
Date: 10/13/99-10:06:55 PM Z
From: Neil Brown <neilb@cse.unsw.edu.au>
Date: Thu, 14 Oct 1999 13:06:55 +1000 (EST)
Message-ID: <14341.18639.347416.28865@notabene.cse.unsw.EDU.AU>
Subject: Re: Feedback on draft-ietf-nfsv4-01 - stateid
On Wednesday October 13, mre@eng.sun.com wrote:
> > Some of the issues:
> >
> > Per-lockowner information is not needed.
>
> The client that wants to do all this work may: simply set the owner field
> to a zero length string. It isn't much extra work for the server to arbitrate
> access on an nfs_lockowner that contains both a clientid and an owner field
> versus one that contains just a clientid field. Since the server has to
> deal with multiple clientid's coming from the same client host (consider
> the scenario of a user-level client co-existing with a kernel-level client
> in an NFS file system), nfs_lockowner needs to include the clientd anyway.
>
> Arbitrating access based on the client's source IP address is going to be
> messy because the client might have multjple IP addresses or it might be using
> dynamic IP address assignmnent. The nfs_lockowner and clientid abstractions
> simplify the server implementaton.
>
> For simple user level clients, that might consist of multiple processes using
> the same suer id and clientid, letting the server do the work simplifies
> client implementation.
>
> Without thinking it through, I suspect that continuing the model of multiple
> nfs_lockowner's per client means that your goal of a single
> stateid per client cannot be achieved, but perhaps I'm wrong. If you
> haven't already entered into a dialog with David Robinson (designer of
> the locking/share protocol), and Dave Noveck (designer of the
> delegation protocol), I suggest you do so.
>
> -mre
Yes, the client could present a single nfs_lockowner if it wanted to,
but should the protocol require the server to deal with multiple
nfs_lockowners per client if doing so complicates the protocol?
Yes, we can't trust client source IP, the "Client" concept is still
very important.
Your "simple user level client" scenario violates the "smart client,
dumb server" principle, which admittedly is not cast in concrete. A
"simple client" could present different "client ids" for the different
processes if it wanted to. It would increase it's lease-extension
workload, but that's it's choice.
Two other issues have occurred to me since I first presented the
single-stateid-per-client idea that are relevant:
1/ How does the server let the client know that it has revoked
the state for a particular file (e.g. revoked a delegation or just
possibly revoked a lock).
With stateid-per-file, it was clear:
any use of the relevant stateid is replied to with
NFS4ERR_EXPIRED
With single-stateid, this must become:
any use of the relevant stateid together with the relevant
filehandle results in NFS4ERR_EXPIRED
However that means that the server must remember all the
filehandles for which is has revoked state.
Alternatively, the client could assert in each request "I believe
I have state for this filehandle" if that is the case. The server
could then reply EXPIRED if doesn't current have any state for the
filehandle with that client.
If the protocol mandated opening before access, which the draft
seems to suggest but is not entirely clear on, then making any
"state related" request (read/write/lock etc. not getattr) would
implicitly assert "I believe I have state", and would be replied
to with NFS4ERR_EXPIRED (or similar) if the file hadn't been
OPENed.
This assumes that the server can only revoke state on a
file+client basis. i.e. it cannot revoke a delegation but still
leave an open active. I don't see this to be a big cost as
revocation only happens when the client is not behaving its self.
(I feel that discussion isn't very clear. Maybe I should write a
"State" chapter to put my ideas in a coherent format.)
2/ Who "owns" the stateid, in terms of what credentials do you need
to change it (i.e. request a state change from this state)?
Possibly more significantly, who "owns" a seqid in the current
proposal?
The seqid or stateid needs to be protected otherwise a denial of
service is possible.
e.g., given the current proposal, a rogue client determines in
some way a valid stateid for a given handle and a given
nfs_lockownr (possibly by guessing, possibly by snooping), and
then makes lots of lock requests with stateid/filehandle and
differing seqid's. Then all the bad seqids will be quietly
ignored (the spec says so) and when the right one is hit, the
server and the client go out-of-sync and cannot continue.
The obvious remedy here (which couldn't apply if we dropped
nfs_lockowners) is to require each lockowner to present with the
same credential every time, so a particular principle could only
hurt themselves. This might work, but it feels restrictive.
The only alternative that I can think of requires stateids to be
"owned" by the principal in the credential that came with the
SETCLIENTID. This would mean for open requests (for example), you
would need 2 principals to be authenticated in the credential: the
principal who owns the client, and the princple who wants access
to the file. But can a credential identify two principals? I haven't
read enough aboue RPCSEC_GSS and GSS yet to be sure, but I doubt it.
(ASIDE:
actually, this is a bit like chgrp in Unix, which requires you to
own the file and be a member of the group, so you need two
credentials. AUTH_SYS allows you to send multiple credentials,
pretending that it is one big credential. How does KerberosV
cope with the possibility of a "newgrp" command? Does it?)
NeilBrown
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:42 AM Z CST