Thanks for sending this note, Chinmay. Good to have the discussion here
instead of on that old Jira issue.
IIRC, EXEC was added since we're already in the context of a CP
execution to make these MetaDataEndpoint calls. Pretty much any time
you're interacting with Phoenix (even just reading a table), you're
executing a CP to fetch the PTable. As such, the expectation was that we
just require the user has 'X' set.
I'm not sure I buy your concern about a user being able to execute a CP
"unintentionally" as there should be no way for them to register a
coprocessor on their own -- an admin would have had to configure it.
Ankit might remember more than I do -- I'll let him chime in too :)
On 7/16/19 8:31 PM, Chinmay Kulkarni wrote:
Why do we need EXEC permissions in PhoenixAccessController#preGetTable?
Aren't READ permissions sufficient here? Now every time that a client calls
MetaDataEndPointImpl#getTable, they will need EXEC permissions on the
table, though they may just want to read from or upsert to the table,
rather than execute any co-processors on the table.
This was introduced as part of changes for PHOENIX-4661
<https://issues.apache.org/jira/browse/PHOENIX-4661>, where we removed
ADMIN permission requirements and added these instead.
I ran into this at $dayjob wherein we had to grant EXEC permissions to a
user just so they could query a table. This doesn't seem right, since
granting EXEC permissions to them could potentially allow them to invoke
any co-processors loaded on that table.
Any ideas about the reasoning behind this? Or is this a potential bug?
