Subject: [nfsv4] unsupported mandatory server features

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 12 Apr 2013 17:01:01 -0400

I'm expecting to turn on basic 4.1 support by default on the Linux
server before supporting two mandatory 4.1 features, and looking for
advice on handling that without too much pain to future clients.  I
suspect I'm not the only server in this situation; anyone know what
others are doing?

The features are:

	- State protection (SSV and MACH_CRED): I'm currently returning
	  SERVERFAULT on EXCHANGE_ID's that request this, but this isn't
	  really what SERVERFAULT is for.

	  I'm inclined to switch to ENC_ALG_UNSUPP; that leaves future
	  clients unable to distinguish between servers lacking SSV
	  entirely from those lacking support for a particular
	  algorithm, but in practice I think they'd handle both in the
	  same way anyway.

	- GSS on the backchannel: currently CREATE_SESSION or
	  BACKCHANNEL_CTL will succeed but SEQUENCE will start returning
	  with the CB_DOWN flag set.  I would rather return an error
	  immediately than make the client guess what's going on in
	  recovery.

	  Could I get away with returning ENC_ALG_UNSUPP here too?  It's
	  not entirely logical, but it's also currently illegal for
	  these two operations so its use wouldn't be confused with some
	  other.

Of course my preference would be just to support these features, but
given resource limitations, the lack of interest, and the lack of any
implementation to test against, that doesn't look likely to happen in
the near future.

--b.

---

From: "Myklebust, Trond" <[email-masked]>
Date: Fri, 12 Apr 2013 21:49:39 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of J. Bruce Fields
> Sent: Friday, April 12, 2013 5:01 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [nfsv4] unsupported mandatory server features
> 
> I'm expecting to turn on basic 4.1 support by default on the Linux server
> before supporting two mandatory 4.1 features, and looking for advice on
> handling that without too much pain to future clients.  I suspect I'm not the
> only server in this situation; anyone know what others are doing?
> 
> The features are:
> 

Why not just reply with NFS4ERR_ENC_ALG_UNSUPP for SP4_SSV (as you suggest) and return an empty spo_must_allow, and minimal spo_must_enforce sets for SP4_MACH_CRED?

By minimal spo_must_enforce, I mean EXCHANGE_ID, CREATE_SESSION, DESTROY_SESSION, BIND_CONN_TO_SESSION, and DESTROY_CLIENTID. I'm assuming that you default to checking the principal name for those anyway since NFSv4 requires it for the corresponding SETCLIENTID/CONFIRM?

> 	  these two operations so its use wouldn't be confused with some

Why not return NFS4ERR_NOENT to tell the client that the handle does not exist?

> Of course my preference would be just to support these features, but given
> resource limitations, the lack of interest, and the lack of any implementation
> to test against, that doesn't look likely to happen in the near future.
> 
> --b.
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 12 Apr 2013 18:06:42 -0400

> By minimal spo_must_enforce, I mean EXCHANGE_ID, CREATE_SESSION, DESTROY_SESSION, BIND_CONN_TO_SESSION, and DESTROY_CLIENTID. I'm assuming that you default to checking the principal name for those…

Yes, I think you're right, I'll try that now!

> Why not return NFS4ERR_NOENT to tell the client that the handle does not exist?

Imagine a client and server both support gss on the backchannel.  The
most likely cause I can think of (bugs aside) for a NFS4ERR_NOENT return
in that case is that the server just purged that context from its cache
for some reason.  It would then seem reasonable for the client to
attempt to recover by establishing a new context and resending with the
new handle.

How would the client distinguish between that case and "sorry, gss on
the backchannel will never work"?

I guess if the server was replying NOENT to a handle over which that
very call was sent then maybe it'd be safe for the client to assume the
latter case.

It seems a little subtle.

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 15 Apr 2013 21:48:33 -0400

> Yes, I think you're right, I'll try that now!

OK, OK, so the minimal SP4_MACH_CRED implementation is a lot easier than
I thought:

fs/nfsd/nfs4state.c |   62 ++++++++++++++++++++++++++++++++++++++++++---------
fs/nfsd/nfs4xdr.c   |    2 +-
fs/nfsd/state.h     |    1 +
3 files changed, 53 insertions(+), 12 deletions(-)

> > Why not return NFS4ERR_NOENT to tell the client that the handle does not exist?

I'm still inclined to return a new error here, though; NOENT seems
already taken for something a client would handle a bit differently.

--b.