Re: RESTRICTED_STATD

[Olaf Kirch <okir@suse.de>]

On Thursday 04 September 2008 08:03:16 Neil Brown wrote:
> If it was to only check one, it would probably to check ip_addr
> against dns_name.

Right. Comparing the mon_name and the the result of the DNS reverse
lookup is additional paranoia, and should be configurable. In some
environments, not all machines will have reverse DNS entries, or
if they do, the name will not necessarily match what they've set
as their hostname. You could argue that this is a broken configuration,
but it is certainly not that uncommon.

> 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.

Yes.

> > > 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.

Me too. The whole NSM thing was totally over-engineered from day one.

Olaf
-- 
 And mention in the Fitz incident that DCOP is no ego shooter!
                                --micha istinie, 2001