Per-document access control

[wohali]

(@janl: Rewriting the issue to reflect the work status)

Todo:

• isolate couch_doc.erl patch to permit new private-to-couchdb field _access, so we can maintain replication compatibility. This can land at any time, and we should at least do one 2.x release with this. If the rest of this doesn’t land for 3.0, this one patch should be in 3.0 for the same reason. (complexity: 1)

• rebase against master. the current WIP branch is about a year old, and while not a lot has changed in the parts, and the patch isn’t that large, some adjustments needs to be made (complexity: 3)

• fix revs_diff endpoint (explanation TBD) (complexity: 1)

• update replicator to write local docs with _access if source and/or target are access-enabled (complexity: 2)

• clean up RFC to be more RFC-like (c.f. Garren’s comments there) (complexity: 1)

• write end-user docs and release notes (complexity: 1)

Old ticket content

@janl says: >I don’t know what this will look like, but this is a pattern, and we need to support it better. > >One approach could be “virtual dbs” that are backed by a single database, but that’s usually at odds with views, so we could make this an XOR and disable views on these dbs. Since this usually powers client-heavy apps, querying usually happens there anyway. > >Another approach would be better / easier cross-db aggregation or querying. There are a few approaches, but nothing really slick.

[janl]

I think this is captured in the _access proposal best: https://lists.apache.org/thread.html/6aa77dd8e5974a3a540758c6902ccb509ab5a2e4802ecf4fd724a5e4@%3Cdev.couchdb.apache.org%3E

[janl]

I keep not finding this issue because of the old title, I hope the change is okay.

[janl]

latest updates on dev@ https://lists.apache.org/thread.html/1aae26aa329817d8c54bab615a0df1c3a7b0fd34f17a2321ecf047f3@%3Cdev.couchdb.apache.org%3E

[janl]

First RFC is up here: apache/couchdb-documentation#424

[janl]

updated main comment to track work progress properly

[natcohen]

@wohali and @janl Any chance we can get that in v3 when it's released?

[wohali]

@natcohen This is slated for the CouchDB 3.x release stream, but was moved out of the 3.0 release due to scheduling conflicts. Sorry about that.

[natcohen]

@wohali Any chance this can land in 4.0?

[wohali]

The plan is to implement it for 4.0, with a stretch goal for 3.x. No news to report.

[janl]

Just posted this on IRC:

[17:21:32] <+jan____> had a good session on per-doc-access today. I think most of the major features are done now, with quite extensive tests: https://github.com/apache/couchdb/blob/access/src/couch/test/couchdb_access_tests.erl#L69-L126
[17:22:40] <+jan____> there are a few niggling todos left and right, but the next major step I’d say is rebase onto master, as this is still in 2.3.1-land. While rebasing, I plan to clean things up a little (take out debug logs, make more review friendly commits).
[17:22:48] <+jan____> but this is exciting to see :)
[17:23:56] <+jan____> especially replication from/to access/non-access enabled dbs seems to work just fine

[kripper]

Any chance to include "support for groups in _access: []" in 4.0?

[janl]

one thing at a time, the plan for now is do just one owner per doc in 3.x and get that out to people. Then we need to rebuild this for the 4.x architecture after which we can think about expanding what can go in _access:[]. I’ve determined that doing groups in 3.x is too hard, but I’m a little more hopeful in 4.x. But again: one thing at a time.

[kripper]

Great! I believe we can simulate roles in _access in the meanwhile by creating a group as a user and sharing this credentials among all (real) users requiring access to this particular docs.

Congratulations Jan! you are solving one of the biggest issues with CouchDB that people have been waiting for for years.

[mehrdad-shokri]

@janl any schedule when one owner per doc comes to 3.x?

[janl]

@mehrdad-shokri absolutely no schedule, but we’re open for sponsorships for this feature to move it along faster.

[joallard]

I've been watching for afar, looks like #3038 is good progress @janl!

I'm trying to track the dependency tree on getting this merged, here's what I can see so far:

• PR feat: per-document-access #3038 (Per-document access)
  • Resolve review comments
  • Write release notes
• RFC at rfc(per-doc-access): first draft couchdb-documentation#424
  • Resolve pending comments
• Open a documentation PR on couchdb-documentation

Anything missing? Anywhere that some help would be welcome?

[wohali]

@joallard The main blocker at this point is getting reviews from the rest of the core committers team. Just right now, those people are very busy with other things (and of course the pandemic is getting in the way).

There are also some specific requests from @janl on #3038 for help, though they require advanced knowledge of our code base.

There will be a CouchDB 3.1.1 release before this gets merged, so expect to see this no sooner than CouchDB 3.2.0.

[alexandrulesi]

Is there any update on this?

[kripper]

We used the approach of storing documents in "per-rol-databases".
Please note that 1 user can have many roles, and 1 role can be assigned to many users.
I believe for most of the use cases you can rethink your security in terms of per-role access instead of per-document access.

[TheRook]

We used the approach of storing documents in "per-rol-databases". Please note that 1 user can have many roles, and 1 role can be assigned to many users. I believe for most of the use cases you can rethink your security in terms of per-role access instead of per-document access.

This feature is important if you want public clients to use an application without middle-ware. In this case you have untrusted public clients, mix-trusted users, and fully trusted administrators, all that need to be managed easily. https://github.com/graphikDB/graphik I think did this quite well, i'm curious if you know of a better example of access control for building client<->db apps.

[gray-heron]

I second to @TheRook . This single issue prevents a plethora of highly distributed, possibly even backendless use cases! Most of then are probably yet-to-be-invented, as very few other storage solutions have such capabilities.

@janl @wohali Are there any news on this?

[klehmann]

I am so much waiting for this feature for years. But given the time it’s been stale, it’s probably best to move on I guess.