svn commit: r192463 - head/sys/fs/nfsserver
jhb at freebsd.org
Fri May 22 15:26:07 UTC 2009
On Friday 22 May 2009 10:32:43 am Rick Macklem wrote:
> On Fri, 22 May 2009, Dag-Erling Smørgrav wrote:
> > Rick Macklem <rmacklem at FreeBSD.org> writes:
> >> Log:
> >> Although it should never happen, all the nfsv4 server can do
> >> when it runs out of clientids is reboot. I had replaced cpu_reboot()
> >> with printf(), since cpu_reboot() doesn't exist for sparc64.
> >> This change replaces the printf() with panic(), so the reboot
> >> would occur for this highly unlikely occurrence.
> > Regardless of how improbable this is, wouldn't it be better (and
> > simpler) to just log an error message and deny further mount requests?
> Well, it this really is an issue I can just take the check for the
> wraparound out and let it continue on.
> Because the likelyhood of a clientid issued 4billion time ago (many
> many years aka centuries, in practice) being for a client that still
> exists and hasn't rebooted or re-acquired a more recent clientid is
> essentialy 0 as well.
> In case you haven't done the calculation, 4billion seconds is 136 years.
> Since I cannot image a server seeing anything close to 1 new clientid/sec
> over an extended period (there could be a burst just after booting), the
> wraparound will take centuries to happen (maybe highly unlikely wasn't a
> strong enough term).
> Just don't worry about it, rick
What about a malicious denial-of-service attack where a malicious client
initiates an endless stream of connection attempts to force a panic? I think
that is where the concern lies. I'm sure a malicious client could do it
intentionally in less than 136 years, perhaps on the order of seconds and/or
More information about the svn-src-all