Uploaded image for project: 'Magnolia UI'
  1. Magnolia UI
  2. MGNLUI-3980

Consider loosening validation of recursive deny permissions

    XMLWordPrintable

Details

    • Improvement
    • Resolution: Won't Do
    • Neutral
    • None
    • 5.4.8
    • security app

    Description

      A. For a custom admin, assigning a deny permission to a fixed node/path requires read/get permission to that node. So far so good.

      B. Now, since MGNLUI-3838:

      We now validate sub-node permissions in a more fine-grained way: in particular, in order to grant a sub-node permission (say RW on /foo sub-nodes), admin must not have any permission to a sub-path of that node, with lower permission (RO on /foo/bar). This way, we now also ensure admins cannot lift their own restrictions by assigning higher-level recursive permissions to another user/role in their control.

      If I get this straight, A. and B. combined mean that the validator converts deny requirement to read, then current user's deny permissions get considered as violations, being lower than read.

      Given a custom admin role with Deny access to /foo/bar (right-side of the screenshot),
      a custom admin user cannot deny permission to /foo (left-side of the screenshot).
      I believe he could, as this cannot lead to lifting one's restrictions.

      Again, this one is also mitigated when superusers manage roles (they can grant anything practically), but needs to be fixed for multi-tenancy scenarios.

      Checklists

        Acceptance criteria

        Attachments

          Issue Links

            Activity

              People

                Unassigned Unassigned
                mgeljic Mikaël Geljić
                Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  Checklists

                    Task DoD