How to set default read only permissions for all databases on creation?
- Dominant language
- Erlang
- Stars
- 7k
- Forks
- 1.1k
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 9
Description
Hello,
Customer has a couchdb environment where databases are created through python scripts in a dynamic way, so we want to ensure that after database creation, it has the appropriate security methods to be accessed with read only permissions with a non admin user.
1. Create a regular user named **dbreader** into the **_users** database. We assign this user a new role named **reader**.
See example of the GET request body:
```
curl -X POST admin:pass@host:5984/_users \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d '{"_id": "org.couchdb.user:dbreader", "name": "dbreader", "password": "xxxx", "roles": ["reader"], "type": "user"}'
```
2. Create **_global_changes** database in order to automate things on database creation.
```
curl -X PUT admin:pass@host:5984/_global_changes
```
3. Create a design document for **_global_changes** database to allow users with **reader** role to access the new databases with a read only mode.
```
curl -X PUT admin:pass@host:5984/_global_changes/_design/reader_readonly
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d '{"validate_doc_update": "function(newDoc, oldDoc, userCtx, secObj) {\n if (userCtx.roles.indexOf('_admin') !== -1) {\n // Admin user, allow update\n return;\n }\n\n if (userCtx.roles.indexOf('reader') !== -1) {\n // Reader user, only allow read\n throw({\n forbidden: 'Read-only access. Updates are not allowed.'\n });\n }\n\n // By default, deny update for other users\n throw({\n unauthorized: 'You are not authorized to update this document.'\n });\n}"}'
```
The JS function checks the role of the user and allows users with admin role to perform update operations and users with reader role to read only.
4. The last piece of the puzzle is to automatically update the **_security** settings on the new databases. Adding something like the code below to the security settings ensure that the users with **reader** role are members and in conjunction with previous point, only can access in read only mode to the database.
```
{"admins": { "names": [], "roles": ["_admin"] }, "members": { "names": [], "roles": ["_admin","reader"] } }
```
The problem is how to achieve this final step using the **_global_changes** database which seems the most appropriate element to do it automatically. I've tried adding a new design document to this database with the following code:
```json
{
"_id": "_design/update_security",
"_rev": "16-d36c1ac2b016a98d9cf266303cdfe22b",
"filters": {
"new_databases": "function(doc, req) { return doc.type === 'created' && doc.db_name && !doc._deleted; }"
},
"updates": {
"modify_security": "function(doc, req) {\n var db = require('kanso/db');\n var dbName = req.query.dbname;\n\n db.get('_security', {db: dbName}, function(err, securityDoc) {\n if (err) {\n return [null, {code: 500, body: err}];\n }\n\n // Modify the securityDoc to update the _security settings of the new database\n // For example, granting read and write access to a specific user or role\n securityDoc.members = {\n names: [],\n roles: ['_admin','reader']\n };\n\n db.save('_security', securityDoc, {db: dbName}, function(err, savedDoc) {\n if (err) {\n return [null, {code: 500, body: err}];\n }\n return [savedDoc, {code: 200, body: 'Security settings updated.'}];\n });\n });\n}"
}
}
```
However, this is not working. I don't know if there is something wrong with the function or the filter or maybe my idea cannot be achieved. Since there is little information on the "doc" object in Couchdb official documentation.
Contributor guide
Research direction
Start with the _global_changes design document, its new_databases filter, and the modify_security update function, then compare them with CouchDB's documented changes and _security APIs. Determine whether these entry points can apply security settings to newly created databases; done means a documented, working procedure or a clear statement that this automation is unsupported.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- authorization, databases
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100