Hi Josh, Thanks for your reply, somehow I missed it, sorry. Currently, if a user 'A' wants to do a "select * from t;" then they need 'RX' permissions on table 't', since as you mentioned, this eventually invokes a CP to fetch the PTable. Though this is correct in theory, but it seems peculiar as an end-user for 'A' to require EXEC permissions on table 't' to read from it.
My point wasn't so much that a user would execute a CP unintentionally, but that, because of this, we would have to grant X permissions to a user just so they could read from it and providing this can now allow them to invoke any other CP on that table. Besides, how will granting just 'R' permissions be useful for any user given this constraint? Seems like they always need 'RX' even if they just want to read. Thanks, Chinmay On Tue, Jul 16, 2019 at 5:59 PM Josh Elser <[email protected]> wrote: > 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? > > > -- Chinmay Kulkarni
