Teiid
  1. Teiid
  2. TEIID-2484

permission condition caching is incorrect

    Details

    • Type: Bug Bug
    • Status: Closed Closed (View Workflow)
    • Priority: Blocker Blocker
    • Resolution: Done
    • Affects Version/s: 8.3
    • Fix Version/s: 8.4
    • Component/s: Query Engine
    • Labels:
      None
    • Workaround:
      Workaround Exists
    • Workaround Description:
      Hide

      Use only a single role in which permission conditions, such as a single any authenticated role.

      Show
      Use only a single role in which permission conditions, such as a single any authenticated role.
    • Similar Issues:
      Show 10 results 

      Description

      The caching of permission conditions is being done across the whole of the roles, which will not be correct for other users with differing subsets of roles.

        Activity

        Hide
        Steven Hawkins
        added a comment -

        There are additional issues:

        If an object has a permission, but no condition then an IllegalArgumentException will be thrown - the workaround is to use a "true" condition
        If an object has conditions from multiple roles, the values are AND'd, not OR'd together - the workaround as with the original issue would be to only use conditions on a single role.

        Show
        Steven Hawkins
        added a comment - There are additional issues: If an object has a permission, but no condition then an IllegalArgumentException will be thrown - the workaround is to use a "true" condition If an object has conditions from multiple roles, the values are AND'd, not OR'd together - the workaround as with the original issue would be to only use conditions on a single role.
        Hide
        Steven Hawkins
        added a comment -

        Addressed the three issues listed and added a check by the validator so that aggregate and other invalid functions produce a better error message.

        A remaining issue is how/whether to apply row-based security during a matview load. The current behaviour is that the load will happen under the current user's roles. Other options are to disable row-based security for a mat view load, to throw an exception if filtering is applied during a load, or to do user scoped matviews (which doesn't seem feasible).

        For internal matviews we can consistently apply the desired behaviour. However external matviews would seemingly require admin accounts as needed to by-pass the affect of row-based security if needed.

        For now we'll just doc the current behaviour (which is somewhat consistent with for example if a source is applying row-based security and a mat view is loaded with an affected user).

        Show
        Steven Hawkins
        added a comment - Addressed the three issues listed and added a check by the validator so that aggregate and other invalid functions produce a better error message. A remaining issue is how/whether to apply row-based security during a matview load. The current behaviour is that the load will happen under the current user's roles. Other options are to disable row-based security for a mat view load, to throw an exception if filtering is applied during a load, or to do user scoped matviews (which doesn't seem feasible). For internal matviews we can consistently apply the desired behaviour. However external matviews would seemingly require admin accounts as needed to by-pass the affect of row-based security if needed. For now we'll just doc the current behaviour (which is somewhat consistent with for example if a source is applying row-based security and a mat view is loaded with an affected user).

          People

          • Assignee:
            Steven Hawkins
            Reporter:
            Steven Hawkins
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: