I agree with David. Making upcalls that wait for the user land to do
something is a bad idea. If you wait for mountd to decide on whether
the client has an export entry or not, it's all too easy to tie up
mountd. With David's queue-the-request-and-redo-it approach, there's
the potential for a memory DoS.
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.
- 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.
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. Either you make exportfs
walk through all entries in the kernel export table, which is about as
bad as the current situation, or you nuke the entire export cache and
make nfsd re-obtain the exports entries for all clients. 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.
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
okir@monad.swb.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
okir@caldera.de +-------------------- Why Not?! -----------------------
UNIX, n.: Spanish manufacturer of fire extinguishers.
The skey oracle says: NIBS RUB TECH LIST LEFT OLAF
-
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/