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.
On Fri, Apr 12, 2013 at 06:06:42PM -0400, J. Bruce Fields wrote:
> On Fri, Apr 12, 2013 at 09:49:39PM +0000, Myklebust, Trond wrote:
> > > -----Original Message-----
> > > From: [email protected] [mailto:[email protected]] On Behalf
> > > Of J. Bruce Fields
> > > Sent: Friday, April 12, 2013 5:01 PM
> > > To: [email protected]
> > > Cc: [email protected]
> > > 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:
> > >
> > > - 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.
> >
> > 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?
>
> 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(-)
> > > - 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.
> >
> > 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.
>
> 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.
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of J. Bruce Fields
> Sent: Friday, April 12, 2013 5:01 PM
> To: [email protected]
> Cc: [email protected]
> 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:
>
> - 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.
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?
> - 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.
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 protected]
> https://www.ietf.org/mailman/listinfo/nfsv4
On Fri, Apr 12, 2013 at 09:49:39PM +0000, Myklebust, Trond wrote:
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf
> > Of J. Bruce Fields
> > Sent: Friday, April 12, 2013 5:01 PM
> > To: [email protected]
> > Cc: [email protected]
> > 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:
> >
> > - 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.
>
> 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?
Yes, I think you're right, I'll try that now!
>
> > - 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.
>
> 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.