[jira] [Comment Edited] (HBASE-24018) Access check for getTableDescriptors is too restrictive

["Geoffrey Jacoby (Jira)" <ji...@apache.org>]

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

Geoffrey Jacoby edited comment on HBASE-24018 at 3/19/20, 12:52 AM:
--------------------------------------------------------------------

[~apurtell] Re-opening because immediately going to Won't Fix without allowing for a response or discussion seems premature. If that's the eventual resolution, or the JIRA gets renamed to something else, that's of course fine. 

To be precise, what's actually needed here is the ability for a user without admin privileges to check for the presence or absence of a coprocessor, not the entire TableDescriptor. This is needed because Phoenix clients have to behave differently depending on whether the legacy or new indexing coprocessor is installed, which will greatly change the behavior on the server. The end user is just trying to do a standard Put through a Phoenix update, but it's failing for lack of Admin privilege. 

The only reason TableDescriptor is needed is because TableDescriptor is the central class needed to get almost _any_ table, column family, or coproc schema information (other than table name). It seems like there are multiple options here that would allow this use case while also addressing the valid concerns about security. For example:

1. Clients without ADMIN privileges get a TableDescriptor populated only with values that are deemed "safe" OR
2. Extra admin methods akin to listTables that provide direct lookups to "safe" information, such as isCoprocessorEnabled(TableName, Class). 

Whether "coprocessor existence" is sensitive is also a necessary discussion. 


was (Author: gjacoby):
[~apurtell] Re-opening because immediately going to Won't Fix without allowing for a response or discussion seems premature. If that's the eventual resolution, or the JIRA gets renamed to something else, that's of course fine. 

To be precise, what's actually needed here is the ability for a user without admin privileges to check for the presence or absence of a coprocessor, not the entire TableDescriptor. This is needed because Phoenix clients have to behave differently depending on whether the legacy or new indexing coprocessor is installed, which will greatly change the behavior on the server. The end user is just trying to do a standard Put through a Phoenix update, but it's failing for lack of Admin privilege. 

The only reason TableDescriptor is needed is because TableDescriptor is the central class needed to get almost _any_ table, column family, or coproc schema information (other than table name). It seems like there are multiple options here that would allow this use case while also addressing the valid concerns about security. For example:

1. Clients without ADMIN privileges get a TableDescriptor populated only with values that are deemed "safe" OR
2. Extra admin methods akin to listTables that provide direct lookups to "safe" information, such as isCoprocessorEnabled(Class clazz). 

Whether "coprocessor existence" is sensitive is also a necessary discussion. 

> Access check for getTableDescriptors is too restrictive
> -------------------------------------------------------
>
>                 Key: HBASE-24018
>                 URL: https://issues.apache.org/jira/browse/HBASE-24018
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Abhishek Singh Chouhan
>            Priority: Major
>
> Currently getTableDescriptor requires a user to have Admin or Create permissions. A client might need to get table descriptors to act accordingly eg. based on an attribute set or a CP loaded. It should not be necessary for the client to have create or admin privileges just to read the descriptor, execute and/or read permission should be sufficient? 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)