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