Details

    • Type: Sub-task
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Now that we have namespaces let's address how we can give admins more flexibility.

      Let's list out the privileges we'd like. Then we can map it to existing privileges and see if we need more.

      So far we have:

      1. Modify namespace descriptor (ie quota, other values)
      2. create namespace
      3. delete namespace
      4. list tables in namespace
      5. create/drop tables in a namespace
      6. All namespace's tables create
      7. All namespace's tables write
      8. All namespace's tables execute
      9. All namespace's tables delete
      10. All namespace's tables admin

      1-3, is currently set to global admin only. Which seems acceptable to me.

        Issue Links

          Activity

          Hide
          toffer Francis Liu added a comment -

          We can have this in 1.0, and leave out the L work for 2.0 I think.

          Sounds good. Let's continue discussion for 'C' in HBASE-12511 as the patch will be uploaded there.

          Show
          toffer Francis Liu added a comment - We can have this in 1.0, and leave out the L work for 2.0 I think. Sounds good. Let's continue discussion for 'C' in HBASE-12511 as the patch will be uploaded there.
          Hide
          enis Enis Soztutar added a comment -

          Needs to be done. Have internal patch.

          We can have this in 1.0, and leave out the L work for 2.0 I think.

          Show
          enis Enis Soztutar added a comment - Needs to be done. Have internal patch. We can have this in 1.0, and leave out the L work for 2.0 I think.
          Hide
          toffer Francis Liu added a comment -

          Just found out a subtask cannot have a subtask created HBASE-12511 and HBASE-12512 in the parent task.

          Show
          toffer Francis Liu added a comment - Just found out a subtask cannot have a subtask created HBASE-12511 and HBASE-12512 in the parent task.
          Hide
          toffer Francis Liu added a comment -

          Yes, let's get it in. Going through the Jira:

          'RWXCA' on the namespace dominates permissions for tables and CFs in the namespace.

          This is already done in a separate Jira.

          'C' on the namespace also allows table creation in the namespace.

          Needs to be done. Have internal patch.

          'A' on the namespace does not grant admin privilege - let's document this exception clearly.

          This is already true. AFAIK.

          Global permissions 'A' and 'C' dominate namespace perms and also grant admin and create perms on the namespace itself.

          This is also true. Need to check.

          adding a new privilege for listing tables and tables in a namespace? "L"?

          This needs to be done.

          So it seems to me 'C' and 'L' privileges are what's missing. We can push 'C' upstream. Which IMHO is one of the most useful privileges. For 'L', will try to get to it, not unless someone has time. Will create two subtasks.

          Show
          toffer Francis Liu added a comment - Yes, let's get it in. Going through the Jira: 'RWXCA' on the namespace dominates permissions for tables and CFs in the namespace. This is already done in a separate Jira. 'C' on the namespace also allows table creation in the namespace. Needs to be done. Have internal patch. 'A' on the namespace does not grant admin privilege - let's document this exception clearly. This is already true. AFAIK. Global permissions 'A' and 'C' dominate namespace perms and also grant admin and create perms on the namespace itself. This is also true. Need to check. adding a new privilege for listing tables and tables in a namespace? "L"? This needs to be done. So it seems to me 'C' and 'L' privileges are what's missing. We can push 'C' upstream. Which IMHO is one of the most useful privileges. For 'L', will try to get to it, not unless someone has time. Will create two subtasks.
          Hide
          stack stack added a comment -

          Francis Liu Should we move out of 1.0? Would be good to have it in.

          Show
          stack stack added a comment - Francis Liu Should we move out of 1.0? Would be good to have it in.
          Hide
          pateljaymin Jaymin Patel added a comment -

          Any updates on this making it in any release ?

          Show
          pateljaymin Jaymin Patel added a comment - Any updates on this making it in any release ?
          Hide
          toffer Francis Liu added a comment -

          We might be able to take this depending on how much attention 0.98 needs this quarter.

          Show
          toffer Francis Liu added a comment - We might be able to take this depending on how much attention 0.98 needs this quarter.
          Hide
          enis Enis Soztutar added a comment -

          Anyone up for taking this for 1.0? I think it is important to get the semantics nailed down and consistent across all levels in the hierarchy. I like the way Andrew presents it in the first comment.

          Show
          enis Enis Soztutar added a comment - Anyone up for taking this for 1.0? I think it is important to get the semantics nailed down and consistent across all levels in the hierarchy. I like the way Andrew presents it in the first comment.
          Hide
          enis Enis Soztutar added a comment -

          Let's try to fix this before 1.0.

          Show
          enis Enis Soztutar added a comment - Let's try to fix this before 1.0.
          Hide
          terrasect Alex Nastetsky added a comment -

          Hi, is this ticket still being worked on? There hasn't been any activity since October.

          Currently, any user can either drop anyone else's table OR that user can not create their own tables, which presents a problem. It looks like this ticket would provide the ability to both have separate permissions in different namespaces, as well as separating the permissions for creating and deleting/dropping tables.

          Show
          terrasect Alex Nastetsky added a comment - Hi, is this ticket still being worked on? There hasn't been any activity since October. Currently, any user can either drop anyone else's table OR that user can not create their own tables, which presents a problem. It looks like this ticket would provide the ability to both have separate permissions in different namespaces, as well as separating the permissions for creating and deleting/dropping tables.
          Hide
          apurtell Andrew Purtell added a comment -

          +1 to L

          Show
          apurtell Andrew Purtell added a comment - +1 to L
          Hide
          toffer Francis Liu added a comment -

          Andrew Purtell It seems we're close to a resolution here. So how about adding a new privilege for listing tables and tables in a namespace? "L"?

          Show
          toffer Francis Liu added a comment - Andrew Purtell It seems we're close to a resolution here. So how about adding a new privilege for listing tables and tables in a namespace? "L"?
          Hide
          toffer Francis Liu added a comment -

          Yep addressed in later minor version of 0.96.

          Show
          toffer Francis Liu added a comment - Yep addressed in later minor version of 0.96.
          Hide
          apurtell Andrew Purtell added a comment -

          No, my understanding is this is a discussion carried over from another namespace JIRA for post 0.96.0.

          Show
          apurtell Andrew Purtell added a comment - No, my understanding is this is a discussion carried over from another namespace JIRA for post 0.96.0.
          Hide
          stack stack added a comment -

          Enis Soztutar My understanding is that it is not (Right Francis Liu and Andrew Purtell?)

          Show
          stack stack added a comment - Enis Soztutar My understanding is that it is not (Right Francis Liu and Andrew Purtell ?)
          Hide
          enis Enis Soztutar added a comment -

          Is this a blocker for 0.96?

          Show
          enis Enis Soztutar added a comment - Is this a blocker for 0.96?
          Hide
          apurtell Andrew Purtell added a comment -

          Thinking about this again. It might just be better to have a privilege which restricts list namespace and list tables by namespace as well as list tables.

          Either way seems fine to me.

          Show
          apurtell Andrew Purtell added a comment - Thinking about this again. It might just be better to have a privilege which restricts list namespace and list tables by namespace as well as list tables. Either way seems fine to me.
          Hide
          toffer Francis Liu added a comment -

          Yep a few minor clarifications:

          'C' on the namespace also allows table creation in the namespace.

          Does not grant create/drop privilege on the namespace, this also needs needs to be documented clearly.

          The AccessController should filter out tables for which the user doesn't have privilege when enumerating descriptors for the list table names APIs. We ignore cell level perms when deciding.

          Thinking about this again. It might just be better to have a privilege which restricts list namespace and list tables by namespace as well as list tables. Tho we currently don't have a use case in either case. But restricting instead of hiding seems to be a more straightforward approach. Will have to see how other DBs do it.

          Show
          toffer Francis Liu added a comment - Yep a few minor clarifications: 'C' on the namespace also allows table creation in the namespace. Does not grant create/drop privilege on the namespace, this also needs needs to be documented clearly. The AccessController should filter out tables for which the user doesn't have privilege when enumerating descriptors for the list table names APIs. We ignore cell level perms when deciding. Thinking about this again. It might just be better to have a privilege which restricts list namespace and list tables by namespace as well as list tables. Tho we currently don't have a use case in either case. But restricting instead of hiding seems to be a more straightforward approach. Will have to see how other DBs do it.
          Hide
          apurtell Andrew Purtell added a comment -

          Tho I don't want namespace 'A' to permit namespace metadata manipulation as that's where we'll store quota information. So if we only allow global 'A' to manipulate namespace metadata then we're set?

          +1

          In which case seems no separate permission for metadata is needed now.

          To summarize current discussion:

          • 'RWXCA' on the namespace dominates permissions for tables and CFs in the namespace.
          • 'C' on the namespace also allows table creation in the namespace.
          • 'A' on the namespace does not grant admin privilege - let's document this exception clearly.
          • Global permissions 'A' and 'C' dominate namespace perms and also grant admin and create perms on the namespace itself.
          • The AccessController should filter out tables for which the user doesn't have privilege when enumerating descriptors for the list table names APIs. We ignore cell level perms when deciding.

          That right?

          Show
          apurtell Andrew Purtell added a comment - Tho I don't want namespace 'A' to permit namespace metadata manipulation as that's where we'll store quota information. So if we only allow global 'A' to manipulate namespace metadata then we're set? +1 In which case seems no separate permission for metadata is needed now. To summarize current discussion: 'RWXCA' on the namespace dominates permissions for tables and CFs in the namespace. 'C' on the namespace also allows table creation in the namespace. 'A' on the namespace does not grant admin privilege - let's document this exception clearly. Global permissions 'A' and 'C' dominate namespace perms and also grant admin and create perms on the namespace itself. The AccessController should filter out tables for which the user doesn't have privilege when enumerating descriptors for the list table names APIs. We ignore cell level perms when deciding. That right?
          Hide
          apurtell Andrew Purtell added a comment -

          Small nitpick, namespace doesn't have schema

          The namespace itself is schema.

          'M' works.

          Shouldn't 'R' on a table be enough to read schema and 'S' for manipulating it

          I don't believe so. Some users want a user or application to be able to read table data yet not be able to access sensitive metadata in the schema, an HCD attribute, for example. That was the motivation for HBASE-8692.

          For #4. On a "list by namespace" command how about we hide tables a user does not have any privilege to?

          There's precedent as AccessControlFilter. So we would have to go back and add a CP hook in getTableNames/listTableNames after all. Maybe a filter like interface for the descriptor enumeration there.

          can we make cell level an exception?

          We could.

          If you have a namespace 'C' then it should translate to being able to create a table in a namespace.

          +1

          Show
          apurtell Andrew Purtell added a comment - Small nitpick, namespace doesn't have schema The namespace itself is schema. 'M' works. Shouldn't 'R' on a table be enough to read schema and 'S' for manipulating it I don't believe so. Some users want a user or application to be able to read table data yet not be able to access sensitive metadata in the schema, an HCD attribute, for example. That was the motivation for HBASE-8692 . For #4. On a "list by namespace" command how about we hide tables a user does not have any privilege to? There's precedent as AccessControlFilter. So we would have to go back and add a CP hook in getTableNames/listTableNames after all. Maybe a filter like interface for the descriptor enumeration there. can we make cell level an exception? We could. If you have a namespace 'C' then it should translate to being able to create a table in a namespace. +1
          Hide
          toffer Francis Liu added a comment -

          and also tangentially related to HBASE-8692, here's a thought: We could introduce a new permission 'S' (SCHEMA) for accessing and manipulating table and namespace schema.

          Thinking about this more we already have 'A' for manipulating table schema. Tho I don't want namespace 'A' to permit namespace metadata manipulation as that's where we'll store quota information. So if we only allow global 'A' to manipulate namespace metadata then we're set?

          Show
          toffer Francis Liu added a comment - and also tangentially related to HBASE-8692 , here's a thought: We could introduce a new permission 'S' (SCHEMA) for accessing and manipulating table and namespace schema. Thinking about this more we already have 'A' for manipulating table schema. Tho I don't want namespace 'A' to permit namespace metadata manipulation as that's where we'll store quota information. So if we only allow global 'A' to manipulate namespace metadata then we're set?
          Hide
          toffer Francis Liu added a comment -

          I see namespaces as another level in a hierarchy of grants: cell, column family, table, namespace, global. List that out in the inverse for the dominance relationship. If we do that, then it addresses:

          I see in that case. 6-10. Should directly map to RWXCA for consistency.

          and also tangentially related to HBASE-8692, here's a thought: We could introduce a new permission 'S' (SCHEMA) for accessing and manipulating table and namespace schema.

          Shouldn't 'R' on a table be enough to read schema and 'S' for manipulating it? Small nitpick, namespace doesn't have schema. So maybe 'M' would be better for metadata?

          For #4. On a "list by namespace" command how about we hide tables a user does not have any privilege to? Tho this seems a bit difficult when it comes down to cell. Or can we make cell level an exception?

          For #5. If you have a namespace 'C' then it should translate to being able to create a table in a namespace.

          Show
          toffer Francis Liu added a comment - I see namespaces as another level in a hierarchy of grants: cell, column family, table, namespace, global. List that out in the inverse for the dominance relationship. If we do that, then it addresses: I see in that case. 6-10. Should directly map to RWXCA for consistency. and also tangentially related to HBASE-8692 , here's a thought: We could introduce a new permission 'S' (SCHEMA) for accessing and manipulating table and namespace schema. Shouldn't 'R' on a table be enough to read schema and 'S' for manipulating it? Small nitpick, namespace doesn't have schema. So maybe 'M' would be better for metadata? For #4. On a "list by namespace" command how about we hide tables a user does not have any privilege to? Tho this seems a bit difficult when it comes down to cell. Or can we make cell level an exception? For #5. If you have a namespace 'C' then it should translate to being able to create a table in a namespace.
          Hide
          apurtell Andrew Purtell added a comment - - edited

          I see namespaces as another level in a hierarchy of grants: cell, column family, table, namespace, global. List that out in the inverse for the dominance relationship. If we do that, then it addresses:

          6. All namespace's tables create
          7. All namespace's tables write
          8. All namespace's tables execute
          9. All namespace's tables delete
          10. All namespace's tables admin

          Agree this sounds reasonable:

          1-3, is currently set to global admin only. Which seems acceptable to me.

          For these:

          4. list tables in namespace
          5. create/drop tables in a namespace

          and also tangentially related to HBASE-8692, here's a thought: We could introduce a new permission 'S' (SCHEMA) for accessing and manipulating table and namespace schema.

          Show
          apurtell Andrew Purtell added a comment - - edited I see namespaces as another level in a hierarchy of grants: cell, column family, table, namespace, global. List that out in the inverse for the dominance relationship. If we do that, then it addresses: 6. All namespace's tables create 7. All namespace's tables write 8. All namespace's tables execute 9. All namespace's tables delete 10. All namespace's tables admin Agree this sounds reasonable: 1-3, is currently set to global admin only. Which seems acceptable to me. For these: 4. list tables in namespace 5. create/drop tables in a namespace and also tangentially related to HBASE-8692 , here's a thought: We could introduce a new permission 'S' (SCHEMA) for accessing and manipulating table and namespace schema.

            People

            • Assignee:
              Unassigned
              Reporter:
              toffer Francis Liu
            • Votes:
              2 Vote for this issue
              Watchers:
              20 Start watching this issue

              Dates

              • Created:
                Updated:

                Development