[SERVER-22733] Need SQL View like capability .. Created: 18/Feb/16  Updated: 07/Oct/16  Resolved: 18/Feb/16

Status: Closed
Project: Core Server
Component/s: Concurrency, Querying, Security, Usability
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Daniel Farrell Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-10788 Writable views Backlog
duplicates SERVER-142 Read-only views over collection data. Closed
Participants:

 Description   

I'd like to request the addition of a SQL View like capability for security.

To be as brief as possible-

. You have a collection with 8 keys. Remove all permission from this
collection for a given user. Create a view that references 6 of the 8
keys. Give permission to this view to the same user. Now this user
can read/write/whatever a vertical slice of this collection. This serves
a use case of data privacy.

OR, create the view with all columns, but a filter criteria is in place.
Eg., where

{ "state" = "NY" }

. Now this user can read/write/whatever
a horizontal slice of this collection. This serves a use case of data
privacy, and multi-tenancy.

. How others (SQL) does this-

The view either enforces the underlying security of the source/
referenced collections, or not.

By default, security is inherited from the source collection. If you
can't read/write the source table, the view will not give you this
ability. In this use case, the view acts more like a macro, and its
value add is to centralize definitions, or code.

If the view is created

{ "with_admin_authority" : true }

, then the view
overrides base permissions. This is how you suppress access to
base collections, yet still poke through any read/write any subsets.
In this case, the user can do whatever read/write they were given
the view object, and not the underlying/base collection object.

You might also want a

{ "with_check_option" }

. In effect, if you
should only see "NY", can you insert "NJ" ?

. Phase 1, I'd be happy with projection and filter, and we'll call these
"simple views". They are writable like a normal collection.

Phase 2, "compound views", containing aggregated keys or simply
keys that are calculated. MongoDB doesn't know how to simply write
back to a calculated key. You can read compound views, but not
update.

. Query optimizer enhancement-

If the view has a filter as part of its definition, and the user adds
filters, yadda, in their request, you should someday flatten all of that,
remove duplicates and such. This is a performance feature only.

. Views on views-

Added someday. Not needed on day one perhaps.



 Comments   
Comment by Daniel Pasette (Inactive) [ 07/Oct/16 ]

This is supported in the current implementation coming in 3.4 and available in development versions. See SERVER-142 for links to documentation.

Comment by John Menke [ 07/Oct/16 ]

Views on Views - is this something that is on the Roadmap?

Comment by Stennie Steneker (Inactive) [ 18/Feb/16 ]

Hi Daniel,

Thanks for your feedback. I'm going to close this as a duplicate of the existing feature suggestion for writable views (SERVER-10788). There is also a prerequisite feature suggestion for readable views (SERVER-142). Please upvote & watch these issues for updates.

Regards,
Stephen

Generated at Thu Feb 08 04:01:16 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.