Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@phoenix.apache.org
Date: Wed, 13 Sep 2017 07:40:02 +0000 (UTC)
From: "Ankit Singhal (JIRA)" <jira@apache.org>
To: dev@phoenix.apache.org
Message-ID: <JIRA.13101631.1505220408000.99286.1505288402388@Atlassian.JIRA>
In-Reply-To: <JIRA.13101631.1505220408000@Atlassian.JIRA>
References: <JIRA.13101631.1505220408000@Atlassian.JIRA> <JIRA.13101631.1505220408931@jira-lw-us.apache.org>
Subject: [jira] [Commented] (PHOENIX-4198) Remove the need for users to have
 access to the Phoenix SYSTEM tables to create tables
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 13 Sep 2017 07:40:10 -0000


    [ https://issues.apache.org/jira/browse/PHOENIX-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16164255#comment-16164255 ] 

Ankit Singhal commented on PHOENIX-4198:
----------------------------------------

Thanks [~tdsilva] for taking the look.

bq. 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 [~elserj]/[~apurtell] on this in my last comment. I can see AccessControlService.Interface has some APIs but they are not yet implemented by Ranger.

bq. 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. 


> 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
>
>
> 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)