Re: [Nbd] Easier use, authentication

[Wouter Verhelst <w@...112...>]

On Fri, Sep 23, 2011 at 04:34:37PM -0400, Christian Jaeger wrote:
> Hi
> 
> I'm often trying to loop-mount (actually with dmcrypt) remote
> (encrypted) filesystem image files. I often do this spontaneously, and
> I often already have a mount of the remote filesystem over sshfs, so I
> can access these image files over the sshfs mount and my "mounte" tool
> automatically takes care of the dmcrypt, thus it's a 1 step process
> for me to mount such image files over sshfs. But sshfs is slow
> (needless additional encryption) and sometimes not working reliably.
> NBD works reliably, but is a pain to setup: I need to configure and
> start a server process, start a client process with correct
> configuration, then choose the right nbd block file to mount. I'd like
> to look into improving that.

Can you explain that a bit? I don't see how you could make that easier,
to be honest, but ideas are always welcome.

> Also, while at it, I'd hope to improve
> the security by offering some kind of challenge-response
> authentication. (I've written about the same thing in more length
> here: http://lists.debian.org/debian-user/2011/09/msg01453.html)

I've been thinking about that too, but it hasn't really happened yet.
There is an 'auth' branch in git which contains a proof-of-concept, but
it probably needs forward-porting and testing.

The reason it hasn't happened is, I guess, that I've let the perfect be
the enemy of the good; TCP hijacking isn't exactly difficult, so I
wasn't sure authentication on the TCP session was a very good idea.

Also, adding authentication requires me to think the security of the
whole thing through very very well, which I was looking a bit up to.

But then, I don't think all that is a very good reason not to have any
decent authentication. If you're willing to look into that, patches are
certainly welcome.

> If I succeed implementing that, NBD should be perfect to me, except
> that it would be nice if the client could try to reconnect if the
> connection fails.

That's what the -persist option was meant for, but I might've made some
mistakes; I've seen reports from people claiming that it didn't work. I
need to look into that in some more detail, but haven't had the time.

> Ah, and it would be nice to somehow ensure that an image file is only
> served at most once for safety :).

That could make sense in some situations, yes, but definitely not all.
Most importantly, though, it's very hard to implement right, the way
nbd-server is currently implemented.

> But I guess NBD is still the right way to look into, since the
> alternative ENBD isn't included in the mainstream kernel?

>From what I've seen, ENBD isn't very active anymore these days, either.
But I could be mistaken.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a