[DOCS-9473] Document behavior of views when auth is enabled Created: 02/Dec/16  Updated: 05/Feb/20  Resolved: 07/Aug/17

Status: Closed
Project: Documentation
Component/s: None
Affects Version/s: None
Fix Version/s: 3.4.0

Type: Task Priority: Major - P3
Reporter: Emily Hall Assignee: Kay Kim (Inactive)
Resolution: Done Votes: 0
Labels: read-only-views
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-27194 Views should require both "viewOn" an... Closed
documents SERVER-24724 Views works with authorization Closed
Related
Participants:
Days since reply: 6 years, 27 weeks, 2 days ago
Epic Link: 3.4: Views

 Description   

We should document how views behave when auth is enabled, because commands that interact with views require specific actions or have restrictions in their authorization checks:

  • create: You must have the createCollection action to create a view. There is also another rule, depending on whether or not you can read the view you're creating:
    • If you can't read the view you're about to create, then createCollection suffices.
    • If you can read the view you're creating, then you must be able to run an aggregation on the view's "viewOn" namespace with the specified view "pipeline".
  • collMod:
    1. You must specify both "viewOn" and "pipeline" when modifying a view; having only one or the other doesn't suffice (see SERVER-27194). (Note that this restriction only applies when auth is enabled.)
    2. You must have the collMod action to modify a view. Like create, there is another rule depending on whether or not you can read the view:
      • If you can't read the view you're modifying, then collMod suffices.
      • If you can read the view you're modifying, then you must be able to run an aggregation on the view's "viewOn" namespace with the specified view "pipeline".
  • all other query operations (find/count/distinct/aggregate): the rules for views are exactly the same for collections. The only noteworthy thing is that a user with the find action on a view can read that view, even if they don't have find on the view's underlying namespace. (I suppose this is the whole point of using views in the first place )

Original Engineering Ticket Description

Access control on views should work exactly as it does for collections.

  • If you can(not) create a collection, then you should (not) be able to create a view

There are also some interesting security concerns to consider with regard to access control on a view's backing namespace:

  • User can read a view when not authorized to read the view's backing namespace(s)
  • If user is (not) authorized to read a collection, they can(not) read a view they create on top of it

However, this ticket *does not* cover authorization checks when calling getMore on a cursor returned by a view. (This means that a user authorized to read a view will still get an authorization error when calling getMore on that cursor.) The work for that will be tracked in SERVER-24771.



 Comments   
Comment by Githook User [ 07/Aug/17 ]

Author:

{'username': 'kay-kim', 'email': 'kay.kim@10gen.com', 'name': 'kay'}

Message: DOCS-9473 DOCS-8900 DOCS-9446 views
Branch: master
https://github.com/mongodb/docs/commit/9918ed56ea4b8a13df20ec12c951150578b9c436

Comment by Githook User [ 07/Aug/17 ]

Author:

{'name': 'kay', 'username': 'kay-kim', 'email': 'kay.kim@10gen.com'}

Message: DOCS-9473 DOCS-8900 DOCS-9446 views
Branch: v3.4
https://github.com/mongodb/docs/commit/85dec7eba6b2171dc0765fbfbdefdb2c4c15a910

Comment by Kyle Suarez [ 07/Dec/16 ]

I don't think I've seen any documentation regarding views and authorization, so I've modified the ticket to describe what I think we should document. (If I'm wrong, and there does exist documentation, please let me know.) Feel free to split this up into sub-tickets, since there are several commands affected.

I've also linked this ticket to both SERVER-24724 and SERVER-27194, since they can both be done at the same time.

Generated at Thu Feb 08 07:58:26 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.