2011/9/26 Wouter Verhelst <[email protected]>: > 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. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
