phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: Why do we need exec permissions in PhoenixAccessController#preGetTable?
Date Wed, 17 Jul 2019 00:58:58 GMT
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
> <>, 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?

View raw message