Subject: [nfsv4] SetClientID specifying no callback path

From: Rick Macklem <[email-masked]>
Date: Tue, 5 Jul 2011 17:22:54 -0400 (EDT)

Hi,

I vaguely recall that specifying "0.0.0.0.0.0" for r_addr in a
SetClientID Op was the agreed upon way to specify "no callback path".

Tom thinks it is a NULL (I assume he means zero length) r_addr.

For the 3 servers I have here to test against (Solaris10, Linux/Fedora15
and FreeBSD), either:
   "tcp", "0.0.0.0.0.0"
and
   "", ""   (zero length r_netid and r_addr)

both work to disable callback attempts. (ie. No CB Null is attempted
by the server and no delegations are issued.)

So, what is the preferred way to specify this?

And am I correct to assume that a server will attempt a CB Null to
verify that the callback path is working before issuing a Delegation
to the client?

Thanks in advance for any help with this, rick

---

From: Thomas Haynes <[email-masked]>
Date: Tue, 5 Jul 2011 17:07:40 -0500

> Tom thinks it is a NULL (I assume he means zero length) r_addr.

From a network trace of z/OS NFSC  client to a filer:

Network File System
    [Program Version: 4]
    [V4 Procedure: COMPOUND (1)]
    Tag: setclientid
        length: 11
        contents: setclientid
        fill bytes: opaque data
    minorversion: 0
    Operations (count: 1)
        Opcode: SETCLIENTID (35)
            client
                verifier: 0xc744f405228d7ea8
                id: <DATA>
                    length: 35
                    contents: <DATA>
                    fill bytes: opaque data
            callback
                cb_program: 0x00000000
                cb_location
                    r_netid: <EMPTY>
                        length: 0
                        contents: <EMPTY>
                    r_addr: <EMPTY>
                        length: 0
                        contents: <EMPTY>
            callback_ident: 0x00000000

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 6 Jul 2011 13:21:12 -0400

> verify that the callback path is working before issuing a Delegation

I seem to recall that being either required or strongly suggested by the
rfc.

On the server side, I think you'd want to silently ignore anything
that's valid xdr but not a usable address.

--b.

---

From: Rick Macklem <[email-masked]>
Date: Wed, 6 Jul 2011 16:57:38 -0400 (EDT)

> I seem to recall that being either required or strongly suggested by
Yea, I think this para from RFC3530 covers the CB Null issue:

   Because callback RPCs may not work in all environments (due to
   firewalls, for example), correct protocol operation does not depend
   on them.  Preliminary testing of callback functionality by means of a
   CB_NULL procedure determines whether callbacks can be supported.  The
   CB_NULL procedure checks the continuity of the callback path.  A
   server makes a preliminary assessment of callback availability to a
   given client and avoids delegating responsibilities until it has
   determined that callbacks are supported.  Because the granting of a
   delegation is always conditional upon the absence of conflicting
   access, clients must not assume that a delegation will be granted and
   they must always be prepared for OPENs to be processed without any
   delegations being granted.

> that's valid xdr but not a usable address.
Agreed, and that's what the FreeBSD server does.

However, since it seems that the RFC says nothing on the issue, I'd
like to find the best compromise for extant servers. I know that
FreeBSD, Fedora15 and Solaris10 understand both the form the FreeBSD
client currently uses and the one Tom has proposed to me. I'll assume
that Tom can test the one he has proposed, so that brings me to...

Does any server implementor not in the above list know if the following
specification for cb_client4 will NOT tell it that there is no valid
callback path?
   0 for program#, r_netid Null str (0 len), r_addr Null str (0 len)

I can easily change the FreeBSD client to use this, but I need to do so
within the next 10days.

I would like to avoid having a server issue the client Delegations when
the callback path is non-functional, for the obvious reasons.

rick

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 7 Jul 2011 08:57:15 -0400

> the callback path is non-functional, for the obvious reasons.

I don't see how that's a risk--the rfc makes it clear that servers
mustn't give out delegations unless it knows it can do callbacks, and
there's no possible way a server could know it can do callbacks given
that as an address.

Perhaps it's conceivable on the other hand that a server might think
it's OK to return something like INVAL to that setclientid, but then the
failure would at least be obvious.

--b.

---

From: Rick Macklem <[email-masked]>
Date: Thu, 7 Jul 2011 18:08:37 -0400 (EDT)

J. Bruce Fields wrote:
> > > I seem to recall that being either required or strongly suggested
> > > by
> > > the
> > > rfc.
> > >
Since it didn't stop this test server from issuing delegations, I think
I'll just leave my client the way it is, since all the other servers
I've tested against seem to understand what I send now.

Thanks for the comments, rick