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