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

Document behavior of views when auth is enabled

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.4.0
    • Component/s: None
    • Labels:
    • Last comment by Customer:
      true
    • Epic Link:
    • Sprint:
      KANBAN BUCKET

      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

              Assignee:
              kay.kim Kay Kim (Inactive)
              Reporter:
              emily.hall Emily Hall
              Participants:
              Last commenter:
              Kay Kim Kay Kim (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Days since reply:
                4 years, 12 weeks, 2 days ago
                Date of 1st Reply: