[
https://issues.apache.org/jira/browse/PHOENIX-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222559#comment-16222559
]
Hadoop QA commented on PHOENIX-4198:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12894379/PHOENIX-4198_v5.patch
against master branch at commit fe13b257e5dfe29581b1c3265d79596f194954cd.
ATTACHMENT ID: 12894379
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ final UserGroupInformation superUser =
UserGroupInformation.createUserForTesting(SUPERUSER, new String[0]);
+ final UserGroupInformation superUser2 =
UserGroupInformation.createUserForTesting("superuser", new String[0]);
+ final UserGroupInformation regularUser =
UserGroupInformation.createUserForTesting("user", new String[0]);
+ final UserGroupInformation groupUser =
UserGroupInformation.createUserForTesting("user2", new String[] {
GROUP_SYSTEM_ACCESS });
+ final UserGroupInformation unprivilegedUser =
UserGroupInformation.createUserForTesting("unprivilegedUser",
+ config.set("hbase.regionserver.wal.codec",
"org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec");
+ grantPermissions(regularUser.getShortUserName(),
PHOENIX_NAMESPACE_MAPPED_SYSTEM_TABLES, Action.READ,
+ grantPermissions(unprivilegedUser.getShortUserName(),
PHOENIX_NAMESPACE_MAPPED_SYSTEM_TABLES,
+ grantPermissions(AuthUtil.toGroupEntry(GROUP_SYSTEM_ACCESS),
PHOENIX_NAMESPACE_MAPPED_SYSTEM_TABLES,
+ grantPermissions(regularUser.getShortUserName(),
Collections.singleton("SYSTEM:SEQUENCE"), Action.WRITE,
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.SetPropertyOnEncodedTableIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ConcurrentMutationsIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.PartialIndexRebuilderIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.rpc.UpdateCacheIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.SetPropertyOnNonEncodedTableIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1579//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1579//console
This message is automatically generated.
> 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, security
> Fix For: 4.13.0
>
> Attachments: PHOENIX-4198.patch, PHOENIX-4198_v2.patch,
> PHOENIX-4198_v3.patch, PHOENIX-4198_v4.patch, PHOENIX-4198_v5.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)
