Re: RESTRICTED_STATD

[Neil Brown <neilb@suse.de>]

On Tuesday September 2, chuck.lever@oracle.com 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.

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 :-)

I'm think I'm happy with removing any support for non-lockd uses for
statd.

NeilBrown