[
https://issues.apache.org/jira/browse/CASSANDRA-9189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-9189:
---------------------------------------
Attachment: 9189.txt
Trival patch to prevent {{DropRoleStatement}} from caching anything about
non-existent roles and added a dtest
[here|https://github.com/riptano/cassandra-dtest/pull/233]
Related: after CASSANDRA-8967 is done, test code could programatically
invalidate the cache between the {{DROP}} and {{CREATE}} statements, but I
think this is worth doing anyway.
> DROP ROLE shouldn't cache information about non-existent roles
> --------------------------------------------------------------
>
> Key: CASSANDRA-9189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9189
> Project: Cassandra
> Issue Type: Bug
> Reporter: Sam Tunnicliffe
> Assignee: Sam Tunnicliffe
> Fix For: 3.0
>
> Attachments: 9189.txt
>
>
> {{DropRoleStatement#checkAccess}} involves a check of the target role's
> superuser status in order to ensure that only superusers can drop another
> with su privileges.
> When used in conjunction with {{IF EXISTS}}, this causes a cache entry for a
> non-existent role to be inserted into the roles cache as
> {{Roles#hasSuperuserStatus}} goes via the cache. {{RolesCache}} is a map from
> a single role to the set of roles of which it has transitively been granted
> (basically a map of {{RoleResource}} -> {{Set<RoleResource>}}). So in this
> case an empty set is cached for the role.
> This can be problematic when the {{DROP ROLE IF EXISTS}} is followed by a
> {{CREATE ROLE}} as until the cache entry expires any authorization request
> for that role will use the cache to fetch the set of roles that need to be
> included in the permission check. Finding an empty set, all authz checks will
> result in failure. This pattern is particularly common in automated tests.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
