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.