You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@druid.apache.org by GitBox <gi...@apache.org> on 2021/09/10 15:59:32 UTC

[GitHub] [druid] zachjsh commented on issue #11689: authorize all tables in sql queries, with fully qualified table names

zachjsh commented on issue #11689:
URL: https://github.com/apache/druid/issues/11689#issuecomment-917017380


   Sounds like a good approach, few questions
   
   1. Would we still have the filtering of results for system tables, based on datasource and state permissions for a particular user? I would think not, since SQL query access for a particular system tables would be granted to a particular system table would be granted to a user. If this is the case, if a admin still wanted to limit the scope that a particular user had for a given table as was able to be done before, how would they do that? Create a view on the system table?
   
   2. If `druid.sql.planner.requireSqlTablePermissions` is enabled,  will authorization in SqlLifecycle.validateAndAuthorize still make 2 attempts with seperate resource types, or just 1 with the new SQL_TABLE resource?
   
   3. what types of permissions do you envision on this new `SQL_TABLE` resource type? READ, WRITE, etc?
   
   4. To alleviate the issue when if a user creates roles with `SQL_TABLE` permissions, and they downgrade the cluster after which these roles wont have access to the underlying datasource anymore, can we create an equivalent DATASOURCE / VIEW permission at the time that the SQL_TABLE permission is created, so that the role can be used in the downgrade path too?
   
   5. My main concern here is only offering authorization for SQL queries and not native queries. Is there a way that we can prevent non-sql access to the datasources that are protected with SQL_TABLE permissions, to help reduce the risk here?


-- 
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: commits-unsubscribe@druid.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org