Not to pile on here but "Once you read your available docs into your DB, you can grant yourself write privileges to every document there." does seem to miss the mark.
All replication is doing is making a copy of data you have access to. You can modify your own copy as you please, it doesn't violate the security of the origin server. If that server allowed you to replicate those changes back, sure, but that is wholly within the origin servers control. The notion that access controls could meaningful propagate to servers outside of the original servers control seems very much like DRM with all its doesn't-work-without-litigation problems. -- Robert Samuel Newson rnew...@apache.org On Wed, 27 Feb 2019, at 20:14, Adam Kocoloski wrote: > > > On Feb 27, 2019, at 3:01 PM, Michael Fair <mich...@daclubhouse.net> wrote: > > > > On Wed, Feb 27, 2019 at 10:36 AM Adam Kocoloski <kocol...@apache.org> wrote: > > > >> Hi Mike, just picking out this one snippet: > >> > >>> On Feb 27, 2019, at 12:16 PM, Michael Fair <mich...@daclubhouse.net> > >> wrote: > >>> > >>> If I get a replica of a database from your server, what, if anything, > >>> prevents me from granting myself access controls to the entire database? > >> > >> Replication is a client of the API like everyone else and cannot bypass > >> the access controls on the source. You can only create a replication which > >> has at most access to all the documents in the database that you can access > >> yourself; i.e. a replication of a database with per-doc access controls > >> enabled may only transfer a subset of the documents in the database. > >> > > > > Right, but generally speaking READ access is very prevalent, WRITE access > > is much more restrictive. > > > > Or are these "access controls" really just the binary "exposed"/"not > > exposed" sort such that had these documents simply gone into a different > > database in the first place, and the view indexes tracked in a "per > > database" way then everything would work as expected? > > > > In fact, maybe "the same doc in multiple user centered databases" is not > > such a bad idea/model to consider. > > > > Currently, I see this idea in Couch that documents belong to a particular > > "named document collection" called a database. A view is really just > > another kind of "named document collection". > > > > What if instead of a "database", there was simply the single universal > > document store and a "database" is then more like a "view" that documents > > became a member of just like a user's access controlled "slice" would be? > > (i.e. the dbname becomes more like of a document access filter and less a > > grouping and storage boundary) > > > > Users then have a "per user scope/database" which they always access > > through when they connect to the server. > > The top level list of "_databases" the user sees is actually just a list of > > those "named collections" that the user can access. To the client side > > APIs nothing really changes for them, what changes is how Couch internally > > organizes itself to make "databases" a construct of the access control > > feature and no longer a structural primitive. > > > > Documents now carry the information about what "named collections" they > > belong to in the same way as what entities are authorized to access them, > > and "databases" basically become a "view" grouping by the "_collections" > > array field member values on each document. > > > > > > Many people have requested the option to expose the same document to > > multiple databases and then use database access rights to enforce per user > > access and share documents between users. I've even wanted this feature > > from time to time. If views have to be modified to hide unauthorized > > documents anyway, this seems a perfect opportunity to address this at the > > same time... > > > > > > ......... > > In this model, a "document collection", whether it be a database, a user, a > > user group, a role, or a role group becomes the entity that the access > > control documents are "authorizing". > > > > In this model, a "view" becomes an identifiable "collection" that can be > > treated like a database. > > Which would make creating views on top of other views becomes something > > much easier to define/express. > > > > > > I'm envisioning that to implement successful "access control" based views, > > each "authorized entity" would have to maintain its own view index. > > Otherwise it's really hard for me to imagine how a reduce function can > > cache any precomputed results because it has no way of knowing that all the > > underlying documents used in the reduce were authorized for the accessing > > entity... All reduce functions would have to run in real time to ensure it > > is only using authorized documents... > > > > If there were a separate index for each authorized entity though (and > > especially if these entities were able to share index buckets where they > > had all the same document access in common), then the reduce function would > > cache data based on each authorized entity because it'd be built up from a > > different view index. > > > > The existing model where indexes are updated whenever they are accessed > > could remain in tact because you wouldn't have to rebuild indeces for > > entities that weren't accessing that view... > > > > This might be what is already planned (it hasn't sounded like it to me > > though). > > And I definitely think changing the perspective to make "databases" a > > function of the access control system and to make views based on "access > > controlled collection results" instead of "databases" would be quite > > powerful... > > > > Regards, > > Mike > > Hi Mike, what you’ve described here is very very similar to what Jan is > building. > > Adam > >
