That was my initial idea. I considered the way kerneld used to work, and
thought it would be too complex, though.
The callback to the user space authentication would be very slow. Can we wait
that long in exp_getclient(), even for a request that we would otherwise have
rejected?
FX: Wanders off in search of caffeine...
... OK. Here's an alternative plan, along the lines of what you suggest.
We add a character device /dev/nfsauth, for kernel->user communication. This
is not a netlink socket for two reasons:
1. I can't find any documentation on netlink sockets.
2. Using a locally-defined character device will allow us to notice
immediately if the user-space daemon dies and closes it, saving
us from waiting forever.
We add a new kind of client entry, the 'negative' client. This is extremely
similar to the negative dentry, and prevents up from looking up
non-authenticated hosts repeatedly.
In exp_getclient(), upon finding that an address has no corresponding client
entry, we...
1. Check whether the authentication chardevice is open.
If not, just return NULL as before.
2. Release the read lock.
3. Send a 'packet' to the nfsauth device containing the IP address in
question.
4. Wait on an 'authentication' wait_queue to be told that a response
has arrived.
5. Re-obtain the read lock.
6. Search again for a client entry for the host requesting service.
6. If a new client entry has appeared, return it if it is a real one,
or return NULL if it's a negative one.
7. If we have timed out or the nfsauth device has closed, complain
loudly and return NULL.
8. Goto 2.
When receiving notification of a request from the kernel, the auth daemon must
add a client entry to the kernel's list, whether it be positive or negative.
We add the possibility of negative client entries to exp_addclient and
exp_delclient, and also make exp_addclient wake up the 'authentication' wait
queue described in (4) above.
We also need to set a timer to periodically wake up exp_getclient(), to prevent
it waiting for ever if there is no response from the authentication daemon.
This periodic function may also want to walk the client list and expire
negative centries.
Better?
Q: How do we combat the potential DoS attack caused by flooding the kernel with
requests from unknown IP addresses? Once they're given negative centries, it's
fine, but while the authentication is happening, the server thread is blocked.
Do we need some way of queueing the request for later, and letting the server
thread go back to serve other requests while it's waiting for an answer?
Would it be permissible to return EAGAIN to the remote client if there's
already a host (or nrservs/2 hosts) waiting for authentication? Or just to
reject the request and hope that they try again anyway?
---- ---- ----
David Woodhouse David.Woodhouse@mvhi.com Office: (+44) 1223 810302
Project Leader, Process Information Systems Mobile: (+44) 976 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/