Messages in this thread | | | Subject | Re: [PATCH (untested)] Subnet support in knfsd. | Date | Mon, 22 Feb 1999 10:58:56 +0000 | From | David Woodhouse <> |
| |
ak@muc.de said: > And this only covers the special case of subnet exports, not NIS > group exports, dns domain wildcard exports, ..... Adding all these to > the kernel is not possible (and not desirable). Matching the > traditional Unix kernel design rule of providing "mechanism not > policy" I think it is best to add some call back mechanism, where the > kernel can ask user space to reauthenticate before refusing a file > handle. mountd could handle this too, e.g. via a netlink socket.
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/
| |