Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-9473

Document behavior of views when auth is enabled

    XMLWordPrintable

Details

    • Task
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • 3.4.0
    • None
    • KANBAN BUCKET
    • true

    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.

      Attachments

        Issue Links

          Activity

            People

              kay.kim@mongodb.com Kay Kim (Inactive)
              emily.hall Emily Hall
              Kay Kim Kay Kim (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:
                4 years, 42 weeks, 3 days ago