aho135 commented on PR #19272:
URL: https://github.com/apache/druid/pull/19272#issuecomment-4209380756

   > I've often believed that WRITE is appropriate for permissions like this, 
on the rationale that the ingestion APIs should only be accessible to people 
with ability to manipulate ingestion objects, which of course requires WRITE 
permission. I guess your mental model is different, one where READ permission 
means the user can see ingestion objects but not necessary manipulate them. I 
wish that the permission model was more fine grained so we could separate READ 
of the data from READ of the ingestion objects.
   > 
   > I wonder, what's the current state of things? What authorization do other 
read-only APIs in `/druid/indexer/v1/...` require? What do the system tables 
`sys.tasks` and `sys.supervisors` check?
   
   Thanks for the review @gianm! 
   > I wish that the permission model was more fine grained so we could 
separate READ of the data from READ of the ingestion objects.
   
   I believe @clintropolis was working on something similar to this with the 
addition of a 
[Policy](https://github.com/apache/druid/blob/master/server/src/main/java/org/apache/druid/server/security/AllowAllAuthorizer.java#L35)
 in the Authorizer to allow more granular control over table reads
   
    > I wonder, what's the current state of things? What authorization do other 
read-only APIs in `/druid/indexer/v1/...` require?
   
   These API's also follow the model where users can READ all ingestion 
objects, but manipulation still requires WRITE. For example, [task 
submission](https://github.com/apache/druid/blob/master/indexing-service/src/main/java/org/apache/druid/indexing/overlord/http/OverlordResource.java#L847)
 requires write, but `/task/{taskid}/status` only requires READ. Even for 
system tables those only require READ access, so I think the changes in this PR 
at least make things consistent with the current state of things


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to