Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.92.1, 0.94.0
    • Fix Version/s: None
    • Component/s: security
    • Labels:
      None

      Description

      In this issue I would like to open discussion for a few minor ACL related improvements. The proposed changes are as follows:

      1. Introduce something like AccessControllerProtocol.checkPermissions(Permission[] permissions) API, so that clients can check access rights before carrying out the operations. We need this kind of operation for HCATALOG-245, which introduces authorization providers for hbase over hcat. We cannot use getUserPermissions() since it requires ADMIN permissions on the global/table level.
      2. getUserPermissions(tableName)/grant/revoke and drop/modify table operations should not check for global CREATE/ADMIN rights, but table CREATE/ADMIN rights. The reasoning is that if a user is able to admin or read from a table, she should be able to read the table's permissions. We can choose whether we want only READ or ADMIN permissions for getUserPermission(). Since we check for global permissions first for table permissions, configuring table access using global permissions will continue to work.
      3. Grant/Revoke global permissions - HBASE-5342 (included for completeness)

      From all 3, we may want to backport the first one to 0.92 since without it, Hive/Hcatalog cannot use Hbase's authorization mechanism effectively.

      I will create subissues and convert HBASE-5342 to a subtask when we get some feedback, and opinions for going further.

        Issue Links

          Activity

          Hide
          Andrew Purtell added a comment -

          Introduce something like AccessControllerProtocol.checkPermissions(Permission[] permissions) API, so that clients can check access rights before carrying out the operations.

          Sounds good.

          getUserPermissions(tableName)/grant/revoke and drop/modify table operations should not check for global CREATE/ADMIN rights, but table CREATE/ADMIN rights.

          This certainly makes sense for grant/revoke.

          However, creating, dropping, or modifying a table has global ramifications on the cluster. When making changes here it should remain possible to require global CREATE/ADMIN rights for those actions by policy. This way a site admin can prevent users from taking actions that perturb region assignment if desired.

          Show
          Andrew Purtell added a comment - Introduce something like AccessControllerProtocol.checkPermissions(Permission[] permissions) API, so that clients can check access rights before carrying out the operations. Sounds good. getUserPermissions(tableName)/grant/revoke and drop/modify table operations should not check for global CREATE/ADMIN rights, but table CREATE/ADMIN rights. This certainly makes sense for grant/revoke. However, creating, dropping, or modifying a table has global ramifications on the cluster. When making changes here it should remain possible to require global CREATE/ADMIN rights for those actions by policy. This way a site admin can prevent users from taking actions that perturb region assignment if desired.
          Hide
          Laxman added a comment -

          Enis & Matt, hope you don't mind if I add some sub-tasks related to ACL here.
          Already added HBASE-6086. Matt clarified this is a duplicate of HBASE-5372.

          Also one more observation I wanted to validate with you.

          Currently, AccessController doesn't provide implementation for some methods like preFlush, preSplit and many others. That means, any unauthorized user can trigger these operations on a table.

          Do we need to handle this in a separate jira?

          Show
          Laxman added a comment - Enis & Matt, hope you don't mind if I add some sub-tasks related to ACL here. Already added HBASE-6086 . Matt clarified this is a duplicate of HBASE-5372 . Also one more observation I wanted to validate with you. Currently, AccessController doesn't provide implementation for some methods like preFlush, preSplit and many others. That means, any unauthorized user can trigger these operations on a table. Do we need to handle this in a separate jira?
          Hide
          Matteo Bertozzi added a comment -

          @Laxman yeah create a sub-task for that, ACL can be not in sync with new features, so fill free to open a new sub-task to sync the coprocessor with the missing stuff.

          Show
          Matteo Bertozzi added a comment - @Laxman yeah create a sub-task for that, ACL can be not in sync with new features, so fill free to open a new sub-task to sync the coprocessor with the missing stuff.
          Hide
          Laxman added a comment -

          Yes Matt, there are many other apis which are not checked for authorization in AccessController. We may need to analyze all together once and handle them in phases. I will try to provide analysis of all the operations. We will discuss after that.

          Thanks for your quick response.

          Show
          Laxman added a comment - Yes Matt, there are many other apis which are not checked for authorization in AccessController. We may need to analyze all together once and handle them in phases. I will try to provide analysis of all the operations. We will discuss after that. Thanks for your quick response.
          Hide
          Andrew Purtell added a comment -

          Originally only the superuser could take such actions, so the AccessController did not need to deal with them. Now that the implementation is changing all of these cases need review. I suggest sub issues for each RPC interface.

          Show
          Andrew Purtell added a comment - Originally only the superuser could take such actions, so the AccessController did not need to deal with them. Now that the implementation is changing all of these cases need review. I suggest sub issues for each RPC interface.
          Hide
          Laxman added a comment -

          Request for review for subtask: HBASE-6092

          Show
          Laxman added a comment - Request for review for subtask: HBASE-6092
          Hide
          Laxman added a comment -

          Patch available for: HBASE-6209, HBASE-6238, HBASE-6192
          Please review.

          Show
          Laxman added a comment - Patch available for: HBASE-6209 , HBASE-6238 , HBASE-6192 Please review.
          Hide
          Laxman added a comment -

          One observation related to operation vs ACL in our [Ram & Laxman] discussion today.

          HBASE-6252 : TABLE ADMIN should be allowed to do assign, unassign & move as these are table level operations.

          Any other opinion?

          Show
          Laxman added a comment - One observation related to operation vs ACL in our [Ram & Laxman] discussion today. HBASE-6252 : TABLE ADMIN should be allowed to do assign, unassign & move as these are table level operations. Any other opinion?
          Hide
          Laxman added a comment -

          Patch available for review : HBASE-6257
          Please review.

          Show
          Laxman added a comment - Patch available for review : HBASE-6257 Please review.
          Hide
          Andrew Purtell added a comment -

          This umbrella has seen it's day. Will spin out still relevant unfinished subtasks to top level issues.

          Show
          Andrew Purtell added a comment - This umbrella has seen it's day. Will spin out still relevant unfinished subtasks to top level issues.

            People

            • Assignee:
              Unassigned
              Reporter:
              Enis Soztutar
            • Votes:
              0 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development