NBD: authentication and named exports

I just did some work on two NBD features: authentication and named exports.

The first was written by Brad Allen back in 2008. I'd been thinking about an authentication scheme back at DebConf 8, and discussed it on the nbd-general mailinglist. Brad picked it up and ran with it, but it never got finished. Basically, what I did today was forward-port the code so that it would compile (and work) with today's version of the NBD utilities.

I tested it and it works, but I'm not sure what to do with it. NBD is not encrypted; so there's no protection against TCP hijacking or some such. Oh well; I might still integrate it into nbd mainline.

The second feature is something way more interesting. It had been on my long-term TODO list for quite a while, but I never sat down to implement it. Until today, that is. This patch has been compile-tested, but I haven't functionally tested it yet; I'll do that tomorrow.

The main reason it took so long to implement, was that initial NBD handshake made that quite hard. Upon connecting, nbd-server as it currently exists will open the file or block device that it needs to export, and—before nbd-client has sent anything—sends information on that export (its size, whether or not it is read-only, etc) to the client. Unfortunately, this does mean that I cannot add new features to nbd-server while retaining full backwards compatibility if these features may involve changing what nbd-server sends during the initial handshake, as is the case here. This could be worked around by having the server first send information on a "default" export to the client, and then variate that if the client informs the server that it actually wants something else. But this would have been rather ugly, since it means that errors in open() or stat() calls for the initial "default" export would have to be non-fatal until the client actually tries to read or write to or from the device, at which point they would suddenly become fatal. This would open a can of worms near which I didn't want to tread.

The way I fixed it in the end, however, is fairly simple. If names are used to specify an export, nbd-server can live with just one port to export all block devices that it supports, rather than needing many. As such, I can "reserve" one port for the new-style named exports. On this port, nbd-server would expect that clients send a name, and would not function correctly with clients that don't understand names. At the same time, nbd-server could still export the same block devices on other ports as well, using the old-style protocol, for clients that do not support named devices.

This would of course require that both the client and the server know perfectly well what the port is, and that it does not change too easily. As such, I've just put in a request for an assigned port number over at IANA, so that I can be sure that the port will not change unexpectedly. This also means I won't make a public release with this change until the port number has been assigned, so that I don't need to support two 'default' nbd-server ports in the future (one "temporary" and one IANA-assigned port).

For now, however, I think I'll go grab some food.