Re: [Nbd] Easier use, authentication

[Christian Jaeger <chrjae@...17...>]

2011/9/26 Wouter Verhelst <w@...112...>:
> otherwise any person could mount any random file

The idea is to just rely on normal user rights. My solution will use
ssh to log in as a non-root user (let's name him foo), and start
nbd-server with the file path it should serve. This means, any
attacker not having the ssh credentials will be unable to get access
to any file user foo doesn't want to be served by nbd-server.

Ah btw I forgot: for my solution, nbd-server should also be able to
allocate a service port by itself (could start at port n, and if
that's already taken, try n+1 etc.), and return the port it's using on
stdout. Well I could work around that missing capability by retrying
to start nbd-server with random or increasing port numbers; but why
write the code in the wrapper when it might be useful for other people
in the server too?

I guess you're thinking (preferring to think) about a world not
involving ssh to start the service, and I realize that I'm perhaps too
shortsighted to rely on ssh. A way to solve my "give-me-a-mapping"
program without involving ssh would be to run an nbd-server 'master'
instance that accepts the path argument over an unencrypted (but
authenticated) connectionk, and the path secured against MITM using
hashing too. I'd still request that for each user that wants to access
the file server there's a unix account and a separate nbd master
instance running as that unix user, to restrict file access. I'm fan
of relying on unix user rights for security, as you can see. Having a
separate server instance for each user needs a separate port, too,
though; if that's not acceptable (and I agree that that's probably not
nice), then I could code up a solution that at least should be safe on
Linux, that runs as root (or non-root that commands a root process to
fork), forks upon connection and sets uid (drops root) upon
authentication, meaning, you'll have one master instance listen on a
predefined port (standard for all nbd-with-master-instance servers)
but still unix user based file access rights. Any other (better)
ideas?

> No, that's not true; the authorization file is fully optional.

Ah, all the better.

I think I know enough now that I could start coding something, but I
think it's not clear yet what will give the most benefit for the
community, so I'm eager for more input.

> Mmm. Yes, well, patches [for hash based safety againt MITM]
> would probably be welcome, but I won't implement that myself.

I've written an infrastructure that did exactly this a couple years
ago (in Perl), it would quite please me to do it again in C; but it's
less important for me than the authentication / easy use part, so I'll
first do those before considering working on this (well it'd be an
outgrowth of the authentication part anyway).

(I wonder a bit whether the authentication + hash-based-safety part
should be a wrapper a la ssl wrapper? Such setups probably always
introduce complexity in the setup, though, (and of course in coding
too) so I'm cool with an integrated solution.)

Christian.