Re: [nfsv4] re: re: NFS4ERR_ADMIN_REVOKE

[Spencer Shepler <[e-mail]>]

On Mon, [e-mail] wrote:
> > We use the NFS4ERR_ADMIN_REVOKED error for indicating when state 
> > [clientid, stateid (either open,lock, or delegation)] has been revoked and 
> > will no longer be accepted by the server.
> 
> Yep. My main concern in this area was "how permanent" this has to be. Which
> you've addressed later. (Put another way when/if the NFS4ERR_ADMIN_REVOKED
> can be replaced by NFS4ERR_EXPIRED.)

Clientid doesn't apply and I think that is understood in that if the
clientid is revoked then NFS4ERR_EXPIRED should be returned, not
NFS4ERR_ADMIN_REVOKED.

> > Once the client as a whole has been marked as revoked, we do not do any 
> > renewing of it.
> > Once the client's state structures are reclaimed (which may be some time 
> > after it has really "expired"), then the client would get back the 
> > NFS4ERR_EXPIRED error.
> 
> This sounds exactly like what my current code will do. (I, also, don't
> expire the client until sometime after the expiry.)
> 
> > The only way for the client to get past this client wide revoke is to then 
> > issue a SETCLIENTID/SETCLIENTID_CONFIRM sequence. This will purge all 
> > revoked state from the client and it can begin anew. Do you do something 
> > like this OR do you make the revoke permanent? That is, require 
> > administrative intervention to lift the embargo on the bad client ?
> 
> I also allow the SetClientID/confirm to lift the embargo, although I am
> still on the fence as to whether or not that should be the case.

The server has to return NFS4ERR_EXPIRED to old state from the client
regardless of how long the client keeps sending it (unless the server
eventually reboots).  Even if the client does a
SETCLIENTID/SETCLIENTID_CONFIRM and is confused enough to send old
state requests, those old state requests still have to receive
NFS4ERR_EXPIRED.

> > We do not tie the revokes to a specific open owner. The main reason being 
> > is that the server hands out clientids and stateids, but not "open 
> > owners". The server only revokes things it hands out.
> 
> This sounds like the only place where our current code differs. I used
> the open/lockowner since it was explicitly referred to in the RFC. (My
> assumption was that the author was thinking that an open/lockowner equates
> to a client process/task that went south without releasing the state as
> it should.) btw, when I say "revoke an openowner" I mean that all stateids
> for all opens and lockowners associated with that openowner will be revoked
> and use of all those stateids will get NFS4ERR_ADMIN_REVOKED.
> 
> My current code could easily be changed to revoke opens instead of openowners.
> 
> Do others see this as an issue? (ie. Does it matter w.r.t the protocol whether
> the openowner with all associated opens or the individual opens, gets revoked?)

Administratively, I would expect that files or shares/exports are the
unit of revocation.  The admin is unlikely to care about openowners
unless there seems to something broken with the NFSv4 client and it
that case the entire client might as well be revoked.

Spencer


_______________________________________________
nfsv4 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nfsv4