Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 May 2009 11:18:48 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        Rick Macklem <rmacklem@uoguelph.ca>
Cc:        svn-src-head@freebsd.org, Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= <des@des.no>, svn-src-all@freebsd.org, src-committers@freebsd.org, Rick Macklem <rmacklem@freebsd.org>
Subject:   Re: svn commit: r192463 - head/sys/fs/nfsserver
Message-ID:  <200905221118.48669.jhb@freebsd.org>
In-Reply-To: <Pine.GSO.4.63.0905221024420.105@muncher.cs.uoguelph.ca>
References:  <200905201858.n4KIw7Fc040619@svn.freebsd.org> <86r5yhzaso.fsf@ds4.des.no> <Pine.GSO.4.63.0905221024420.105@muncher.cs.uoguelph.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 22 May 2009 10:32:43 am Rick Macklem wrote:
>=20
> On Fri, 22 May 2009, Dag-Erling Sm=F8rgrav wrote:
>=20
> > Rick Macklem <rmacklem@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.
>=20
> Why?
>=20
> 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.
>=20
> 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).
>=20
> Just don't worry about it, rick

What about a malicious denial-of-service attack where a malicious client=20
initiates an endless stream of connection attempts to force a panic?  I thi=
nk=20
that is where the concern lies.  I'm sure a malicious client could do it=20
intentionally in less than 136 years, perhaps on the order of seconds and/o=
r=20
minutes? :)

=2D-=20
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200905221118.48669.jhb>