> > > It'd be awesome if FDB had the option to be/do something like a SQLite > > library or work over a spawned PIPE or something to lock it down so only > > the Couch server instance that launched it could use it... > > TLS and TCP are non-negligable overheads, but this may not matter much in > practise. This is what I was thinking of with UNIX domain sockets. So I > asked: > > > https://forums.foundationdb.org/t/feature-request-support-unix-domain-sockets-for-client-local-server-access/1071 > > UDS works for those platforms that have it, and my Windows and mobile devices don't. ;-)
There's the SASL library from way back that was designed to help servers with exactly this problem... Here's a thought, in FDB's xFF data set, add a "secured prefix" section where the value is a symmetric key. This wouldn't password protect based on the idea of "users" but by "key prefix" instead. When trying to access a particular subtree you must prove you know the secret (I think it would be kind of silly to just pass the secret in cleartext as part of the request, but there are many fast hash algorithms to prove you know it). I guess from there it's not too hard to allow multiple named passwords to unlock access; and that's equivalent to a username/password system... Changing the secret requires access to xFF section which should also be password protected and subkeys of xFF could be protected with different passwords (allowing different apps to change their own subtree of passwords without access to change higher levels). For the "cluster level" access, the protected key would be the "Couch Instance Namespace" key, and each machine could be given its own id/password. Over time that model might even grow to support key based ACLs. =============== Seeing how this could work, in this seemingly straight forward and relatively basic/simple model, satisfies in my mind's eye that this protection feature can/should arrive at some point in the not too distant future. Likely by the time CouchDB is looking at making a formal FDB based release. Thoughts? Thanks! Mike
