Sandboxing is useful when you are running applications, in a defined environment (like an OS), you can't trust, not libraries, but applications. For example in iOS all the apps are sandboxed, not the system libraries. But no one can't run an application inside CouchDB if CouchDB can't be accessed from outside. You can't do the equivalent of SQL injection in CouchDB using CouchDB as simple DBMS. An user can't insert a ddoc in it if you can connect to CouchDB just from the localhost and you don't know the admin's username and pass. The only person able to write ddocs is the application developer, and I'm pretty sure he won't delete the root directory in a map function. When used as a pure database, CouchDB is not an environment, it's a database, something to store documents, using a client. CouchDB used to run Couch apps instead is an environment, it acts like an OS in which the applications run. In this case, maybe, you need a sandbox. I mean, the only needs I see for sandboxing here is when you have a company selling CouchDB as a service, and running any kind of third part applications, or as I said, when you are using CouchDB as the environment in which the couch apps run. I'm not saying sandboxing is useless, I'm saying is something optional a sys admin should enable in case of need.
-Filippo On Oct 16, 2013, at 11:03 PM, Alexander Shorin wrote: > Because you are running your code and you trust yourself (I hope so). > Another user may not trust you or your code, so he have to inspect > every bit of your code to make sure that it wouldn't make a big > security hole in his server. Having sandboxing feature guarantees him > that he may run third party code with no worries about. > > -- > ,,,^..^,,,
