On Friday 22 May 2009 10:32:43 am Rick Macklem wrote: > > On Fri, 22 May 2009, Dag-Erling Smørgrav wrote: > > > Rick Macklem <rmack...@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. > > Why? > > 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 minutes? :) -- John Baldwin _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
