cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-9189) DROP ROLE shouldn't cache information about non-existent roles
Date Tue, 14 Apr 2015 21:49:58 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-9189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jonathan Ellis updated CASSANDRA-9189:
--------------------------------------
    Reviewer: Aleksey Yeschenko

> 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)

Mime
View raw message