[
https://issues.apache.org/jira/browse/PHOENIX-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16172641#comment-16172641
]
Josh Elser commented on PHOENIX-4198:
-------------------------------------
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)}}
{noformat}
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)
{noformat}
This only seems to happen with this patch enabled.
> Remove the need for users to have access to the Phoenix SYSTEM tables to
> create tables
> --------------------------------------------------------------------------------------
>
> Key: PHOENIX-4198
> URL: https://issues.apache.org/jira/browse/PHOENIX-4198
> Project: Phoenix
> Issue Type: Bug
> Reporter: Ankit Singhal
> Assignee: Ankit Singhal
> Labels: namespaces
> Fix For: 4.12.0
>
> Attachments: PHOENIX-4198.patch, PHOENIX-4198_v2.patch
>
>
> 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] 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 [~elserj] for the write-up.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
