Update docs on private DB security

[SukantGujar]

Hi,

From the current documentation in the readme, and looking into the code, I think the privateDBs are not restricted to just the user_ids they are based on. E.g. If I am logged in as A so long as I know B's user_id (and private DB URL), I can read/write to it.

Considering the above assumption is right, how can I add a design doc with validate_doc_update function to disallow users whose id won't match with the DB name? If I can do that, then even if the userID is leaked, a different user won't be able to read/write into this user's DB even after guessing the DBURL. Although CouchDB is new to me, I don't think I can get DB Name within the validate_doc_update function. As an alternative, is there a way in which I can match the logged in user's ID with the DBUrl on the server (although I take it that once the client has the DB URL, all requests would directly hit the remote CouchDB, not go through the express app)?

My intention is to prevent any user other than the privateDB user from having any access to it.

Thanks in advance!

[colinskow]

@SukantGujar you should find the answer to your question in the Database Security section of the README. SuperLogin doesn't do it for you (except on Cloudant). You need to study up on CouchDB security best practices and apply them yourself.

You can use the user-db-added event to seed a validate_doc_update design doc.

If you have read the README and the articles linked and are still having trouble let me know.

[SukantGujar]

Yes Colin, I went through the Readme and from the security best practices link as well (thanks, it was really very thoughtful of you to provide that). As pointed out by Matt in his blog, CouchDB security is not very intuitive and I am still trying to understand it :smiley: . I just wanted to know if Superlogin already gives me easier means to go ahead and secure private DBs, over vanilla CouchDB.

About having authorization check within validate_doc_update, wouldn't Superlogin already add it for me if I keep it in one of the design docs used for privateDB? Then maybe I won't need to do it myself explicitly.

After posting this question yesterday, I went through CouchDBs documentation on security. Now I am inclining towards adding the private DB owner to its members collection which should ensure only the owner can access it for read/write/replication needs. What are your thoughts?

[colinskow]

If validate_doc_update is inside a designDoc under userDBs.model then it should automatically be seeded.

SuperLogin will automatically add the private DB owner's session token to its members collection when they login, and will remove them when they log out of the session. You don't need to do this yourself.

In addition if you look in config.example.js under userDBs.defaultSecurityRoles you and copy what I have there it will block anonymous rights by default. (Test it afterward to make sure. You will need to do this manually for databases that already exist.)

[SukantGujar]

Great, so looks like Superlogin already takes care of some of the steps to ensure privateDBs remain accessible only to their owners. IMHO, it may help adopters if the readme has some more clarity on the concept of privateDBs like how they are initialized and what default security features are already added. And what responsibilities should be handled by the adopters.

Thanks for all your help Colin, I am closing this issue.

[colinskow]

I agree the README needs some clarity. I am going to leave this issue open to remind me.