You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A user that has DROP permissions on a keyspace cannot DROP types, but can drop tables fine. This was discussed with @hectorgcr on Slack.
The user has the following permissions:
GRANT CREATE ON ALL KEYSPACES TO accounts_api;
Then as accounts_api create a keyspace and a type, then try to drop the type. Since accounts_api is creating the keyspace it should get full permissions on that keyspace.
CREATE KEYSPACE accounts_api_test;
CREATE TYPE IF NOT EXISTS accounts_api_test.mytype (id TEXT);
DROP TYPE accounts_api_test.mytype;
Gives an error:
Unauthorized: Error from server: code=2100 [Unauthorized] message="Unauthorized. User accounts_api has no DROP permission on <all keyspaces> or any of its parents
DROP TYPE accounts_api_test.mytype;
^^^^
(ql error -4)"
But the user has DROP permissions on that keyspace:
> SELECT * FROM system_auth.role_permissions WHERE resource = 'data/accounts_api_test';
role | resource | permissions
--------------+------------------------+--------------------------------------------------------------
accounts_api | data/accounts_api_test | ['ALTER', 'AUTHORIZE', 'CREATE', 'DROP', 'MODIFY', 'SELECT']
(1 rows)
Workaround for now is to give the user global DROP privileges as well as CREATE privileges.
The text was updated successfully, but these errors were encountered:
We currently check for DROP TYPE permissions in two places:
PTDropStmt::Analyze and in QLProcessor::CheckPermissions.
In PTDropStmt::Analyze we do the check:
case OBJECT_TYPE:
RETURN_NOT_OK(sem_context->CheckHasAllKeyspacesPermission(loc(),
PermissionType::DROP_PERMISSION));
This needs to be changed so that we only check that the current role has the DROP permission on the keyspace the type belongs to instead of checking that the role has the DROP permission on ALL KEYSPACES. We need to do the same check in QLProcessor::CheckPermissions
A user that has
DROP
permissions on a keyspace cannot DROP types, but can drop tables fine. This was discussed with @hectorgcr on Slack.The user has the following permissions:
Then as
accounts_api
create a keyspace and a type, then try to drop the type. Sinceaccounts_api
is creating the keyspace it should get full permissions on that keyspace.Gives an error:
But the user has DROP permissions on that keyspace:
Workaround for now is to give the user global DROP privileges as well as CREATE privileges.
The text was updated successfully, but these errors were encountered: