Affected Version
0.13.0, 0.14.0
Description
SQL queries on sys.* tables currently require the following permission:
{
"resource": {
"name": "sys",
"type": "DATASOURCE"
},
"action": "READ"
}
In one sense, this is incorrect since "sys" is a schema and not a datasource-like table, so the permission needed should really be on something like "sys.segments". This occurs because the following block in DruidPlanner only checks the first part of the table's qualified name:
if (node instanceof Bindables.BindableTableScan) {
Bindables.BindableTableScan bts = (Bindables.BindableTableScan) node;
RelOptTable table = bts.getTable();
String tableName = table.getQualifiedName().get(0);
datasourceNames.add(tableName);
}
In another sense, treating these system tables as a "datasource" is not consistent with the equivalent non-SQL APIs.
Retrieving information about a datasource's segments via MetadataResource APIs only requires datasource-read permissions, and not a higher level "view segment information" permission, which is what a permission on "sys.segments' would represent.
The non-SQL APIs only require additional STATE-read permissions for APIs involving server information (http://druid.io/docs/latest/development/extensions-core/druid-basic-security.html#defining-permissions has more info).
The permissions needed for system table access could be adjusted to not require additional permissions beyond datasource-specific permissions for non-server related info (segments, tasks) and to require STATE-read permissions for server-related tables (servers, server_segments) to be consistent with the non-SQL APIs.
It's worth mentioning here that there is some inconsistency in the non-SQL task APIs themselves. The task APIs in OverlordResource only require datasource permissions, but the running tasks do contain information about where they exist (server-related info). On the other hand, retrieving task info from the middle managers via WorkerResource requires STATE but not datasource permissions.
Affected Version
0.13.0, 0.14.0
Description
SQL queries on
sys.*tables currently require the following permission:In one sense, this is incorrect since "sys" is a schema and not a datasource-like table, so the permission needed should really be on something like "sys.segments". This occurs because the following block in DruidPlanner only checks the first part of the table's qualified name:
In another sense, treating these system tables as a "datasource" is not consistent with the equivalent non-SQL APIs.
Retrieving information about a datasource's segments via MetadataResource APIs only requires datasource-read permissions, and not a higher level "view segment information" permission, which is what a permission on "sys.segments' would represent.
The non-SQL APIs only require additional STATE-read permissions for APIs involving server information (http://druid.io/docs/latest/development/extensions-core/druid-basic-security.html#defining-permissions has more info).
The permissions needed for system table access could be adjusted to not require additional permissions beyond datasource-specific permissions for non-server related info (segments, tasks) and to require STATE-read permissions for server-related tables (servers, server_segments) to be consistent with the non-SQL APIs.
It's worth mentioning here that there is some inconsistency in the non-SQL task APIs themselves. The task APIs in OverlordResource only require datasource permissions, but the running tasks do contain information about where they exist (server-related info). On the other hand, retrieving task info from the middle managers via WorkerResource requires STATE but not datasource permissions.