phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas D'Silva (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-4198) Remove the need for users to have access to the Phoenix SYSTEM tables to create tables
Date Tue, 31 Oct 2017 19:13:00 GMT

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

Thomas D'Silva commented on PHOENIX-4198:
-----------------------------------------

bq. I'm not sure if we can do it as a part of PHOENIX-672 as how can we give access to the
tables which doesn't exist. For eg: User1 has RX access on the table and CREATE access on
the namespace, but he should not be allowed to create an Index until all users of the data
table have access to the new Index table.

Once PHOENIX-672 is complete, we should only use GRANT/REVOKE statements to grant or revoke
permissions. The GRANT/REVOKE command will only allow you to grant or revoke permissions on
a table. If the table has any indexes or if it has a view that has any indexes the same permissions
are automatically granted or revoked from the index tables. 

In PhoenixAccessController. preCreateTable, for indexes we need authorizeOrGrantAccessToUsers()
to automatically grant all users/groups who have any permissions on the parent table the same
permissions on the index table. So I think we don't need the isAutomaticGrantEnabled option.

This change can also be done as part of PHOENIX-672, if you think that makes more sense.

Related to this, why is automatic grant not allowed for groups?
{code}
+                                if(AuthUtil.isGroupPrincipal(Bytes.toString(userPermission.getUser()))){
+                                    AUDITLOG.warn("Users of GROUP:" + Bytes.toString(userPermission.getUser())
+                                            + " will not have following access " + requireAccess
+                                            + " to the newly created index " + toTable
+                                            + ", Automatic grant is not yet allowed on Groups");
+                                    continue;
+                                }
{code}

> 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, PHOENIX-4198_v6.patch, PHOENIX-4198_v7.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)

Mime
View raw message