Hi Neil-
On Sep 4, 2008, at Sep 4, 2008, 2:03 AM, Neil Brown wrote:
On Tuesday September 2, chuck.lever@xxxxxxxxxx wrote:
Only NOTIFY can come from other hosts (to tell us they rebooted).
Right. sm_notify_1_svc() grabs the callers IP address with
svc_getcaller(rqstp->rq_xprt)->sin_addr
It converts this to a string and checks this against lp->dns_name, in
addition to checking the mon_name that was originally registered to
be
monitored. Shouldn't statd check only mon_name against dns_name?
Why
does it check both?
If it was to only check one, it would probably to check ip_addr
against dns_name.
The IP address of that the SM_NOTIFY came from is the most reliable
thing we have to identify which host just rebooted. We use that to
find a 'dns_name' when we first MONitor a host, and use that name for
the file stored in /var/lib/nfs/sm. We then match the source of
SM_NOTIFY against those file names.
Honestly, I would have thought exactly the opposite is true. How
would that work with multi-homed peers? Or with peers that might get
their IP addresses via DHCP?
AFAICT the reason why using only mon_name is sometimes broken is
because the Linux implementation (and it is probably not alone in this
regard) chooses a mon_name that is often not unique.
Sometimes it's simply the unqualified hostname. If you have a
"joe.server.example.com" and a "joe.desktop.example.com" it would be
pretty difficult for statd to distinguish them by their unqualified
hostnames alone.
Really lockd/sm-notify should select a mon_name with a better
guarantee of uniqueness. A base64 hash of one of the NICs on the
peer, for example, would be much better. Hash in the wall clock time
and date, and store it in a file in /var/lib/nfs so it doesn't change
if the NIC hardware is moved.
Is there any guidance in the Open Group standard on how to match
SM_NOTIFY requests to SM_MON? I had thought it was "use the mon_name,
Luke".
So I think this part of the code really does need to be IPv6-aware.
Certainly matchhostname does.
However we don't really want any user to be able to request a
callback
to any random service....
I wonder if anyone uses for statd for anything but lockd, and how
could we know?
I think the real question is whether we should continue to support
this "off-label" use. It adds complexity and security problems, and
the code paths that support this aren't ever tested these days, I'm
willing to bet.
How about we subtly break it, and then we nobody complains for 12
months, remove it as it was broken anyway :-)
And normally I would take that approach. In this case, folks want
real IPv6 support yesterday...
I'm think I'm happy with removing any support for non-lockd uses for
statd.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
