> With David's queue-the-request-and-redo-it approach, there's
> the potential for a memory DoS.
That's not my approach. Ideally, I'd like to chuck the whole request up
the pipe to mountd. mountd can then either return ESTALE itself or stick
the request back into the kernel's incoming request queue, as it sees fit.
That way, we don't really need the negative export entries, and we don't
drop requests while we're trying to decide whether to authorise a client.
The reason I didn't do this straight away was because it requires rather
fundamental hacking to the RPC layer, to allow mountd to respond on behalf
of nfsd, and to allow mountd to inject requests into nfsd's incoming
queue.
>
> Other potential DoS attacks:
>
> - when you cache nagative entries, flooding the server
> with requests from 10.*.*.* may tie up its memory.
> Why not simply drop requests from unauthorized clients
> (maybe except for the NULL procedure) rather than returning
> ESTALE? That way, when an unauthorized request comes in,
> an upcall is made to mountd, mountd finds there's no
> export entry, and just does nothing.
So stick a timeout on the negative entries which gets shorter when there
are more such entries. Or implement what I suggested above.
>
> - There are servers out there that export to the world.
> An attacker can tie up their memory by flooding the
> server with _legal_ requests. Thus, you need to
> limit the number of positive cache entries.
Timeouts. Now we've got to the concept of the kernel's list as a cache
rather than a definitive list, we can afford just to drop a host from it
when it hasn't made a request for a certain period of time.
>
> Of course, these upcalls do not solve all your consistency woes--consider
> what happens if you modify the flags from read-write to read-only on
> a netgroup export, or you create a more specific export for the same
> directory, which has a different set of flags.
...
> With the drop and let the client retry the call, everybody is taking a
> performance hiccup. OTOH, you probably don't change the export table
> that often.
There should be a way of selectively disabling the cached entries which
are obsoleted, rather than just trashing the cache entirely.
---- ---- ----
David Woodhouse David.Woodhouse@mvhi.com Office: (+44) 1223 810302
Project Leader, Process Information Systems Mobile: (+44) 7976 658355
Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/