Uploaded image for project: 'Phoenix'
  1. Phoenix
  2. PHOENIX-4198

Remove the need for users to have access to the Phoenix SYSTEM tables to create tables

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 4.12.0
    • Labels:

      Description

      Problem statement:-
      A user who doesn't have access to a table should also not be able to modify Phoenix Metadata. Currently, every user required to have a write permission to SYSTEM tables which is a security concern as they can create/alter/drop/corrupt meta data of any other table without proper access to the corresponding physical tables.

      Devaraj Das recommended a solution as below.
      1. A coprocessor endpoint would be implemented and all write accesses to the catalog table would have to necessarily go through that. The 'hbase' user would own that table. Today, there is MetaDataEndpointImpl that's run on the RS where the catalog is hosted, and that could be enhanced to serve the purpose we need.
      2. The regionserver hosting the catalog table would do the needful for all catalog updates - creating the mutations as needed, that is.
      3. The coprocessor endpoint could use Ranger to do necessary authorization checks before updating the catalog table. So for example, if a user doesn't have authorization to create a table in a certain namespace, or update the schema, etc., it can reject such requests outright. Only after successful validations, does it perform the operations (physical operations to do with creating the table, and updating the catalog table with the necessary mutations).
      4. In essence, the code that implements dealing with DDLs, would be hosted in the catalog table endpoint. The client code would be really thin, and it would just invoke the endpoint with the necessary info. The additional thing that needs to be done in the endpoint is the validation of authorization to prevent unauthorized users from making changes to someone else's tables/schemas/etc. For example, one should be able to create a view on a table if he has read access on the base table. That mutation on the catalog table would be permitted. For changing the schema (adding a new column for example), the said user would need write permission on the table... etc etc.

      Thanks Josh Elser for the write-up.

      1. PHOENIX-4198_v2.patch
        131 kB
        Ankit Singhal
      2. PHOENIX-4198.patch
        105 kB
        Ankit Singhal

        Activity

        Hide
        ankit@apache.org Ankit Singhal added a comment -

        PFA, a wip patch for the same. Currently,
        Create table/index/view

        • A user who has a CREATE access on schema/namespace can create table/view/index. We also need read access to the data table for view and index but not sure which API (common in Ranger/native authorization) we can use. Josh Elser/Andrew Purtell any idea?

        Drop table/index/view

        • A user who has CREATE access on physical/data table can drop table/index/view. Same we need write access to the physical table, not sure which API I can use?

        Alter(Add/drop column,properties) table/index/view

        • A user who has CREATE access on physical/data table can alter table/index/view.

        Create/drop schema

        • A user who has GLOBAL ADMIN access can create and drop the schema.
        Show
        ankit@apache.org Ankit Singhal added a comment - PFA, a wip patch for the same. Currently, Create table/index/view A user who has a CREATE access on schema/namespace can create table/view/index. We also need read access to the data table for view and index but not sure which API (common in Ranger/native authorization) we can use. Josh Elser / Andrew Purtell any idea? Drop table/index/view A user who has CREATE access on physical/data table can drop table/index/view. Same we need write access to the physical table, not sure which API I can use? Alter(Add/drop column,properties) table/index/view A user who has CREATE access on physical/data table can alter table/index/view. Create/drop schema A user who has GLOBAL ADMIN access can create and drop the schema.
        Hide
        elserj Josh Elser added a comment -

        Thanks for working on this one, Ankit. This has definitely been a repeated ask I've seen come across my "desk".

        Make sure to add a JUnit Category annotation to TableDDLPermissionsIT otherwise you'll run into PHOENIX-4191. Does it make sense to consolidate that test with SystemTablePermissionsIT?

        mutateRowsWithLocks(...) seems a little weird – when we're doing the new code-path, we don't explicitly grab any locks whereas I'd assume that does happen in the other codepath. Is that OK?

        Looks OK at a high-level to me, but I should bring it down and play with it locally too

        FYI James Taylor

        Show
        elserj Josh Elser added a comment - Thanks for working on this one, Ankit. This has definitely been a repeated ask I've seen come across my "desk". Make sure to add a JUnit Category annotation to TableDDLPermissionsIT otherwise you'll run into PHOENIX-4191 . Does it make sense to consolidate that test with SystemTablePermissionsIT ? mutateRowsWithLocks(...) seems a little weird – when we're doing the new code-path, we don't explicitly grab any locks whereas I'd assume that does happen in the other codepath. Is that OK? Looks OK at a high-level to me, but I should bring it down and play with it locally too FYI James Taylor
        Hide
        tdsilva Thomas D'Silva added a comment -

        If a user has read access to a base table, will they be able to create a view? Or will the user need CREATE access on the namespace?
        Any thoughts on if we should be doing something similar for SequenceRegionObserver, currently users need write access to SYSTEM.SEQUENCE in order to use sequences.

        Show
        tdsilva Thomas D'Silva added a comment - If a user has read access to a base table, will they be able to create a view? Or will the user need CREATE access on the namespace? Any thoughts on if we should be doing something similar for SequenceRegionObserver, currently users need write access to SYSTEM.SEQUENCE in order to use sequences.
        Hide
        ankit@apache.org Ankit Singhal added a comment -

        Thanks Thomas D'Silva for taking the look.

        If a user has read access to a base table, will they be able to create a view? Or will the user need CREATE access on the namespace?

        I'm still looking for the API(available in both Ranger and HBase) to check read access on the base table. I seek help from Josh Elser/Andrew Purtell on this in my last comment. I can see AccessControlService.Interface has some APIs but they are not yet implemented by Ranger.

        Any thoughts on if we should be doing something similar for SequenceRegionObserver, currently users need a write access to SYSTEM.SEQUENCE in order to use sequences.

        Currently, we are using the authorization provided by HBase/Ranger so do you know which user access( on schema/table) is required by the regular user to create/increment the sequences.

        Show
        ankit@apache.org Ankit Singhal added a comment - Thanks Thomas D'Silva for taking the look. If a user has read access to a base table, will they be able to create a view? Or will the user need CREATE access on the namespace? I'm still looking for the API(available in both Ranger and HBase) to check read access on the base table. I seek help from Josh Elser / Andrew Purtell on this in my last comment. I can see AccessControlService.Interface has some APIs but they are not yet implemented by Ranger. Any thoughts on if we should be doing something similar for SequenceRegionObserver, currently users need a write access to SYSTEM.SEQUENCE in order to use sequences. Currently, we are using the authorization provided by HBase/Ranger so do you know which user access( on schema/table) is required by the regular user to create/increment the sequences.
        Hide
        elserj Josh Elser added a comment -

        I'm still looking for the API(available in both Ranger and HBase) to check read access on the base table. I seek help from Josh Elser/Andrew Purtell on this in my last comment. I can see AccessControlService.Interface has some APIs but they are not yet implemented by Ranger.

        Sorry, I forgot to address this point yesterday. Enis Soztutar might also be good to bother. I'm of the opinion that if HBase exposes an API for the purpose of what you need to accomplish a task but Ranger doesn't implement that method, that's a Ranger problem. Doesn't mean that is the wrong API call to use

        Show
        elserj Josh Elser added a comment - I'm still looking for the API(available in both Ranger and HBase) to check read access on the base table. I seek help from Josh Elser/Andrew Purtell on this in my last comment. I can see AccessControlService.Interface has some APIs but they are not yet implemented by Ranger. Sorry, I forgot to address this point yesterday. Enis Soztutar might also be good to bother. I'm of the opinion that if HBase exposes an API for the purpose of what you need to accomplish a task but Ranger doesn't implement that method, that's a Ranger problem. Doesn't mean that is the wrong API call to use
        Hide
        apurtell Andrew Purtell added a comment -

        I think Phoenix should use HBase native security features, there is no need to require use of a third party component like Ranger or Sentry. If Ranger or Sentry offer something compelling, fine, a user is free to pick them up and use them, but mandating them is IMHO mandating user lock-in on something external to HBase+Phoenix for what is a core functional concern (protection of SYSTEM tables). That is the wrong approach. HBase+Phoenix should natively provide protection of SYSTEM tables as required.

        Also, there are already a lot of downstream dependencies for a Phoenix build due to all of the connector modules, and the cross-product of these already present a challenge to DIY-ers trying to orchestrate a whole stack for production.

        Show
        apurtell Andrew Purtell added a comment - I think Phoenix should use HBase native security features, there is no need to require use of a third party component like Ranger or Sentry. If Ranger or Sentry offer something compelling, fine, a user is free to pick them up and use them, but mandating them is IMHO mandating user lock-in on something external to HBase+Phoenix for what is a core functional concern (protection of SYSTEM tables). That is the wrong approach. HBase+Phoenix should natively provide protection of SYSTEM tables as required. Also, there are already a lot of downstream dependencies for a Phoenix build due to all of the connector modules, and the cross-product of these already present a challenge to DIY-ers trying to orchestrate a whole stack for production.
        Hide
        elserj Josh Elser added a comment -

        I think Phoenix should use HBase native security features, there is no need to require use of a third party component like Ranger or Sentry.

        As I understand, that is what Ankit is doing (using the AccessControlService interface). I believe he did some legwork to realize that one of these third-party components didn't actually implement the full interface, and would thus not actually work. I'll let Ankit confirm, but I think you are of the same opinion that I am – Ranger (or Sentry) not implementing the full interface is not our problem and not something we should care about.

        Show
        elserj Josh Elser added a comment - I think Phoenix should use HBase native security features, there is no need to require use of a third party component like Ranger or Sentry. As I understand, that is what Ankit is doing (using the AccessControlService interface). I believe he did some legwork to realize that one of these third-party components didn't actually implement the full interface, and would thus not actually work. I'll let Ankit confirm, but I think you are of the same opinion that I am – Ranger (or Sentry) not implementing the full interface is not our problem and not something we should care about.
        Hide
        tdsilva Thomas D'Silva added a comment -

        Ankit Singhal The user only needs write access to SYSTEM.SEQUENCE to get the next value for a sequence. Thinking about this more, even if we use this approach to not require that a user has write access to SYSTEM.SEQUENCE a user can still access any sequence by using SELECT NEXT VALUE for, so maybe that should be addressed separately.

        Are the changes in MetadataEndpointImpl that use LockManager required because even if you run as the HBase user calling region.mutateRowsWithLock still uses the original user context ?

        Show
        tdsilva Thomas D'Silva added a comment - Ankit Singhal The user only needs write access to SYSTEM.SEQUENCE to get the next value for a sequence. Thinking about this more, even if we use this approach to not require that a user has write access to SYSTEM.SEQUENCE a user can still access any sequence by using SELECT NEXT VALUE for, so maybe that should be addressed separately. Are the changes in MetadataEndpointImpl that use LockManager required because even if you run as the HBase user calling region.mutateRowsWithLock still uses the original user context ?
        Hide
        sergey.soldatov Sergey Soldatov added a comment -

        Ankit Singhal
        In QueryServicesOptions.java there is a new import of net.sf.ehcache.config.TerracottaConfiguration.Consistency. Is it incorrect IDE autoimport ?

        Show
        sergey.soldatov Sergey Soldatov added a comment - Ankit Singhal In QueryServicesOptions.java there is a new import of net.sf.ehcache.config.TerracottaConfiguration.Consistency. Is it incorrect IDE autoimport ?
        Hide
        ankit@apache.org Ankit Singhal added a comment -

        Thanks Andrew Purtell,Josh Elser,Thomas D'Silva,Sergey Soldatov for the comments.

        Make sure to add a JUnit Category annotation to TableDDLPermissionsIT otherwise you'll run into PHOENIX-4191. Does it make sense to consolidate that test with SystemTablePermissionsIT?

        Annotated with a category for now. Yes, we probably can remove SystemTablePermissionsIT now.

        mutateRowsWithLocks(...) seems a little weird – when we're doing the new code-path, we don't explicitly grab any locks whereas I'd assume that does happen in the other codepath. Is that OK?

        Actually, if ACL access is not enabled, we do it with the earlier logic(region.mutateRowsWithLocks) where region server acquiring read locks again during mutation. Not sure why we had required this with a single region of the system.catalog table as we were already taking lock before, does it ensure that all rows are written atomically which Htable.batch will not? are there any consequences of writing set of mutations with HTable.Batch which is not there in region.mutateRowsWithLocks?

        but mandating them is IMHO mandating user lock-in on something external to HBase+Phoenix for what is a core functional concern (protection of SYSTEM tables)

        Yes Andrew Purtell, as Josh Elser also clear my point that we are not making Phoenix dependent on any third party component for access control for DDLs operation. The purpose is just to use the right set of public API so that third-party component can also work automatically in future along with HBase Native access control if they implement the APIs required for it.

        I believe he did some legwork to realize that one of these third-party components didn't actually implement the full interface, and would thus not actually work. I'll let Ankit confirm, but I think you are of the same opinion that I am – Ranger (or Sentry) not implementing the full interface is not our problem and not something we should care about.

        yes, Ranger or Sentry will not work until they implement the AccessControlService.Interface#getUserPermissions API

        Thinking about this more, even if we use this approach to not require that a user has write access to SYSTEM.SEQUENCE a user can still access any sequence by using SELECT NEXT VALUE for, so maybe that should be addressed separately.

        Yes, We may need to take it in separate JIRA, as we need to treat sequences as another entity which currently doesn't exist in HBase

        Are the changes in MetadataEndpointImpl that use LockManager required because even if you run as the HBase user calling region.mutateRowsWithLock still uses the original user context ?

        Yes Thomas D'Silva that's why we need to create a new RPC using HTable to change the user context.

        In QueryServicesOptions.java there is a new import of net.sf.ehcache.config.TerracottaConfiguration.Consistency. Is it incorrect IDE autoimport ?

        Sergey Soldatov, removed from newer version

        Show
        ankit@apache.org Ankit Singhal added a comment - Thanks Andrew Purtell , Josh Elser , Thomas D'Silva , Sergey Soldatov for the comments. Make sure to add a JUnit Category annotation to TableDDLPermissionsIT otherwise you'll run into PHOENIX-4191 . Does it make sense to consolidate that test with SystemTablePermissionsIT? Annotated with a category for now. Yes, we probably can remove SystemTablePermissionsIT now. mutateRowsWithLocks(...) seems a little weird – when we're doing the new code-path, we don't explicitly grab any locks whereas I'd assume that does happen in the other codepath. Is that OK? Actually, if ACL access is not enabled, we do it with the earlier logic(region.mutateRowsWithLocks) where region server acquiring read locks again during mutation. Not sure why we had required this with a single region of the system.catalog table as we were already taking lock before, does it ensure that all rows are written atomically which Htable.batch will not? are there any consequences of writing set of mutations with HTable.Batch which is not there in region.mutateRowsWithLocks? but mandating them is IMHO mandating user lock-in on something external to HBase+Phoenix for what is a core functional concern (protection of SYSTEM tables) Yes Andrew Purtell , as Josh Elser also clear my point that we are not making Phoenix dependent on any third party component for access control for DDLs operation. The purpose is just to use the right set of public API so that third-party component can also work automatically in future along with HBase Native access control if they implement the APIs required for it. I believe he did some legwork to realize that one of these third-party components didn't actually implement the full interface, and would thus not actually work. I'll let Ankit confirm, but I think you are of the same opinion that I am – Ranger (or Sentry) not implementing the full interface is not our problem and not something we should care about. yes, Ranger or Sentry will not work until they implement the AccessControlService.Interface#getUserPermissions API Thinking about this more, even if we use this approach to not require that a user has write access to SYSTEM.SEQUENCE a user can still access any sequence by using SELECT NEXT VALUE for, so maybe that should be addressed separately. Yes, We may need to take it in separate JIRA, as we need to treat sequences as another entity which currently doesn't exist in HBase Are the changes in MetadataEndpointImpl that use LockManager required because even if you run as the HBase user calling region.mutateRowsWithLock still uses the original user context ? Yes Thomas D'Silva that's why we need to create a new RPC using HTable to change the user context. In QueryServicesOptions.java there is a new import of net.sf.ehcache.config.TerracottaConfiguration.Consistency. Is it incorrect IDE autoimport ? Sergey Soldatov , removed from newer version
        Hide
        ankit@apache.org Ankit Singhal added a comment -

        guys, can you please look into the new patch.
        New changes include:-
        1. Creating/Dropping view requires read access on the data table. Dropping of view with indexes requires CREATE access on view index table.
        2. Creating index requires read access on the data table and CREATE access in schema/namespace. And, while creating an index we need to give read access to all users who have read access to data table to ensure that the user queries with new index should work without access problem. so a new question arises that is it safe to provide grants to other users from coprocessor without user consent or should we just check the access and throw an error and keep this as a manual step?

        Show
        ankit@apache.org Ankit Singhal added a comment - guys, can you please look into the new patch. New changes include:- 1. Creating/Dropping view requires read access on the data table. Dropping of view with indexes requires CREATE access on view index table. 2. Creating index requires read access on the data table and CREATE access in schema/namespace. And, while creating an index we need to give read access to all users who have read access to data table to ensure that the user queries with new index should work without access problem. so a new question arises that is it safe to provide grants to other users from coprocessor without user consent or should we just check the access and throw an error and keep this as a manual step?
        Hide
        jamestaylor James Taylor added a comment - - edited

        How about we target this JIRA for 4.13? I'd like to get a 4.12 RC up in a few days. Also, will this cooperate with PHOENIX-3534 which enables the SYSTEM.CATALOG to be split across more than one RS?

        Show
        jamestaylor James Taylor added a comment - - edited How about we target this JIRA for 4.13? I'd like to get a 4.12 RC up in a few days. Also, will this cooperate with PHOENIX-3534 which enables the SYSTEM.CATALOG to be split across more than one RS?
        Hide
        elserj Josh Elser added a comment -

        How about we target this JIRA for 4.13? I'd like to get a 4.12 RC up in a few days.

        For $dayjob reasons, I'd like to see this one get in 4.12, but not for any technical reason. I understand this not holding up 4.12.

        Show
        elserj Josh Elser added a comment - How about we target this JIRA for 4.13? I'd like to get a 4.12 RC up in a few days. For $dayjob reasons, I'd like to see this one get in 4.12, but not for any technical reason. I understand this not holding up 4.12.
        Hide
        elserj Josh Elser added a comment -

        will this cooperate with PHOENIX-3534 which enables the SYSTEM.CATALOG to be split across more than one RS?

        Will ultimately defer to Ankit, but my understanding is "yes". We're not actually deferring to exclusion as a part of the "single JVM" of the current model, just tweaking our call to the AccessController to be less exclusive in which clients (really, which clients with certain permissions) are allowed to perform some operations.

        Show
        elserj Josh Elser added a comment - will this cooperate with PHOENIX-3534 which enables the SYSTEM.CATALOG to be split across more than one RS? Will ultimately defer to Ankit, but my understanding is "yes". We're not actually deferring to exclusion as a part of the "single JVM" of the current model, just tweaking our call to the AccessController to be less exclusive in which clients (really, which clients with certain permissions) are allowed to perform some operations.
        Hide
        jamestaylor James Taylor added a comment -

        For $dayjob reasons, I'd like to see this one get in 4.12, but not for any technical reason. I understand this not holding up 4.12.

        Just don't want to destabilize anything so close to when we're cutting 4.12. Lot's of stabilization fixes I'd like to get released as soon as possible.

        Show
        jamestaylor James Taylor added a comment - For $dayjob reasons, I'd like to see this one get in 4.12, but not for any technical reason. I understand this not holding up 4.12. Just don't want to destabilize anything so close to when we're cutting 4.12. Lot's of stabilization fixes I'd like to get released as soon as possible.
        Hide
        elserj Josh Elser added a comment -

        Just don't want to destabilize anything so close to when we're cutting 4.12

        Yup, completely understood and no animosity is held. A close eye on this would be appreciated from (all of) you fine folks as the $dayjob train keeps rolling.

        Show
        elserj Josh Elser added a comment - Just don't want to destabilize anything so close to when we're cutting 4.12 Yup, completely understood and no animosity is held. A close eye on this would be appreciated from (all of) you fine folks as the $dayjob train keeps rolling.
        Hide
        tdsilva Thomas D'Silva added a comment -

        Actually, if ACL access is not enabled, we do it with the earlier logic(region.mutateRowsWithLocks) where region server acquiring read locks again during mutation. Not sure why we had required this with a single region of the system.catalog table as we were already taking lock before, does it ensure that all rows are written atomically which Htable.batch will not? are there any consequences of writing set of mutations with HTable.Batch which is not there in region.mutateRowsWithLocks?

        Since we already acquire the required locks before calling HTable.Batch would that be atomic as well ?

        If a user has create access on the namespace can he create a view, or does he also need read access on the data table to create the view?

        I think for creating an index a user should have create access for the schema/namespace.
        While creating an index users that have read access on the data table should also be granted read access on the index. Users that have write access on the table should be granted write access on the index, and for mutable indexes they should be given execute access on the data table (so that the index metadata can be sent to the server).

        Karan Mehta is working on PHOENIX-672 which can be used to grant users permissions to the index when permissions are granted on the data table.

        Show
        tdsilva Thomas D'Silva added a comment - Actually, if ACL access is not enabled, we do it with the earlier logic(region.mutateRowsWithLocks) where region server acquiring read locks again during mutation. Not sure why we had required this with a single region of the system.catalog table as we were already taking lock before, does it ensure that all rows are written atomically which Htable.batch will not? are there any consequences of writing set of mutations with HTable.Batch which is not there in region.mutateRowsWithLocks? Since we already acquire the required locks before calling HTable.Batch would that be atomic as well ? If a user has create access on the namespace can he create a view, or does he also need read access on the data table to create the view? I think for creating an index a user should have create access for the schema/namespace. While creating an index users that have read access on the data table should also be granted read access on the index. Users that have write access on the table should be granted write access on the index, and for mutable indexes they should be given execute access on the data table (so that the index metadata can be sent to the server). Karan Mehta is working on PHOENIX-672 which can be used to grant users permissions to the index when permissions are granted on the data table.
        Hide
        sergey.soldatov Sergey Soldatov added a comment -

        Ankit Singhal there is a problem in kerberos setup. In hasAccess you are checking for the User.getName value, but hbase acl uses short names, so in the index scenario when user has namespace access we are able to create tables, but unable to create index tables (actually physical table is created, but after that fails during the check that user has access to the parent table).

        Show
        sergey.soldatov Sergey Soldatov added a comment - Ankit Singhal there is a problem in kerberos setup. In hasAccess you are checking for the User.getName value, but hbase acl uses short names, so in the index scenario when user has namespace access we are able to create tables, but unable to create index tables (actually physical table is created, but after that fails during the check that user has access to the parent table).
        Hide
        elserj Josh Elser added a comment -

        I'm running into another scenario which is failing (on laptop, HBase 1.3.1, tip of master+this patch

        • Set phoenix.acls.enabled=true and phoenix.schema.isNamespaceMappingEnabled=true
        • create schema foo
        • create table foo.bar(pk varchar not null primary key)
        • drop table foo.bar

        At this point, SYSTEM.CATALOG contains no records for FOO.BAR and the HBase table does not exist.

        • Then, rerun the same DDL create table foo.bar(pk varchar not null primary key)
          0: jdbc:phoenix:localhost:2181:/hbase-1.3> create table test.foo(pk varchar not null primary key);
          Error: ERROR 1013 (42M04): Table already exists. tableName=TEST.FOO (state=42M04,code=1013)
          org.apache.phoenix.schema.NewerTableAlreadyExistsException: ERROR 1013 (42M04): Table already exists. tableName=TEST.FOO
          	at org.apache.phoenix.schema.MetaDataClient.createTableInternal(MetaDataClient.java:2621)
          	at org.apache.phoenix.schema.MetaDataClient.createTable(MetaDataClient.java:1041)
          	at org.apache.phoenix.compile.CreateTableCompiler$2.execute(CreateTableCompiler.java:212)
          	at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:393)
          	at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:376)
          	at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
          	at org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:375)
          	at org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:363)
          	at org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1707)
          	at sqlline.Commands.execute(Commands.java:822)
          	at sqlline.Commands.sql(Commands.java:732)
          	at sqlline.SqlLine.dispatch(SqlLine.java:813)
          	at sqlline.SqlLine.begin(SqlLine.java:686)
          	at sqlline.SqlLine.start(SqlLine.java:398)
          	at sqlline.SqlLine.main(SqlLine.java:291)
          

        This only seems to happen with this patch enabled.

        Show
        elserj Josh Elser added a comment - I'm running into another scenario which is failing (on laptop, HBase 1.3.1, tip of master+this patch Set phoenix.acls.enabled=true and phoenix.schema.isNamespaceMappingEnabled=true create schema foo create table foo.bar(pk varchar not null primary key) drop table foo.bar At this point, SYSTEM.CATALOG contains no records for FOO.BAR and the HBase table does not exist. Then, rerun the same DDL create table foo.bar(pk varchar not null primary key) 0: jdbc:phoenix:localhost:2181:/hbase-1.3> create table test.foo(pk varchar not null primary key); Error: ERROR 1013 (42M04): Table already exists. tableName=TEST.FOO (state=42M04,code=1013) org.apache.phoenix.schema.NewerTableAlreadyExistsException: ERROR 1013 (42M04): Table already exists. tableName=TEST.FOO at org.apache.phoenix.schema.MetaDataClient.createTableInternal(MetaDataClient.java:2621) at org.apache.phoenix.schema.MetaDataClient.createTable(MetaDataClient.java:1041) at org.apache.phoenix.compile.CreateTableCompiler$2.execute(CreateTableCompiler.java:212) at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:393) at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:376) at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53) at org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:375) at org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:363) at org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1707) at sqlline.Commands.execute(Commands.java:822) at sqlline.Commands.sql(Commands.java:732) at sqlline.SqlLine.dispatch(SqlLine.java:813) at sqlline.SqlLine.begin(SqlLine.java:686) at sqlline.SqlLine.start(SqlLine.java:398) at sqlline.SqlLine.main(SqlLine.java:291) This only seems to happen with this patch enabled.
        Hide
        sergey.soldatov Sergey Soldatov added a comment -

        There is an another problem. There is no check for the superuser. So if the table was created by user X and hbase user tries to create an index, the query would fail because we check only for the table permissions (which has only user X, but not hbase).

        Show
        sergey.soldatov Sergey Soldatov added a comment - There is an another problem. There is no check for the superuser. So if the table was created by user X and hbase user tries to create an index, the query would fail because we check only for the table permissions (which has only user X, but not hbase).

          People

          • Assignee:
            ankit@apache.org Ankit Singhal
            Reporter:
            ankit@apache.org Ankit Singhal
          • Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated:

              Development