Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Granting a ROLE to another ROLE causes incorrect permissions errors #4062

Closed
hectorgcr opened this issue Mar 24, 2020 · 0 comments
Closed

Granting a ROLE to another ROLE causes incorrect permissions errors #4062

hectorgcr opened this issue Mar 24, 2020 · 0 comments
Assignees
Labels
area/docdb YugabyteDB core features kind/bug This issue is a bug priority/high High Priority

Comments

@hectorgcr
Copy link
Contributor

Currently the following statements cause an incorrect error:

Use HELP for help.
cassandra@cqlsh> CREATE KEYSPACE k;
cassandra@cqlsh> USE k;
cassandra@cqlsh:k> CREATE TABLE k.t (id BIGINT, s TEXT, PRIMARY KEY(id));
cassandra@cqlsh:k> CREATE ROLE r1 WITH PASSWORD = 'p' AND LOGIN = true;
cassandra@cqlsh:k> CREATE ROLE r2 WITH PASSWORD = 'p' AND LOGIN = true;
cassandra@cqlsh:k> GRANT r1 TO r2;
cassandra@cqlsh:k> GRANT SELECT ON t TO r2;
cassandra@cqlsh:k> CREATE ROLE r3 WITH PASSWORD = 'p' AND LOGIN = true;
cassandra@cqlsh:k> GRANT r2 TO r3;
cassandra@cqlsh:k> GRANT MODIFY ON t TO r3;
cassandra@cqlsh:k> LOGIN r3;
Password: 
r3@cqlsh:k> INSERT INTO t (id,s) VALUES (123, 'abc');
Unauthorized: Error from server: code=2100 [Unauthorized] message="Unauthorized. User r3 has no MODIFY permission on <table k.t> or any of its parents
INSERT INTO t (id,s) VALUES (123, 'abc');
       ^^^^
 (ql error -4)"
r3@cqlsh:k> 

But removing statement GRANT r2 TO r3; fixes the issue:

[cqlsh 5.0.1 | Cassandra 3.9-SNAPSHOT | CQL spec 3.4.2 | Native protocol v4]
Use HELP for help.
cassandra@cqlsh> CREATE KEYSPACE k;
cassandra@cqlsh> USE k;
cassandra@cqlsh:k> CREATE TABLE k.t (id BIGINT, s TEXT, PRIMARY KEY(id));
cassandra@cqlsh:k> CREATE ROLE r1 WITH PASSWORD = 'p' AND LOGIN = true;
cassandra@cqlsh:k> CREATE ROLE r2 WITH PASSWORD = 'p' AND LOGIN = true;
cassandra@cqlsh:k> GRANT r1 TO r2;
cassandra@cqlsh:k> GRANT SELECT ON t TO r2;
cassandra@cqlsh:k> CREATE ROLE r3 WITH PASSWORD = 'p' AND LOGIN = true;
cassandra@cqlsh:k> GRANT MODIFY ON t TO r3;
cassandra@cqlsh:k> LOGIN r3;
Password: 
r3@cqlsh:k> INSERT INTO t (id,s) VALUES (123, 'abc');
r3@cqlsh:k> 
@hectorgcr hectorgcr added the kind/bug This issue is a bug label Mar 24, 2020
@hectorgcr hectorgcr self-assigned this Mar 24, 2020
@bmatican bmatican added area/docdb YugabyteDB core features priority/high High Priority labels Mar 24, 2020
hectorgcr added a commit that referenced this issue Mar 25, 2020
… the client's cache

Summary:
Currently, when processing permissions for a specific resource in the cache,  we could end up replacing a permission already in the cache for the same resource. This only affects the cache and not the permissions that are stored on disk.

For example:
If for role r, the cache has permission MODIFY for resource t, and we process another permission SELECT for the same resource, we will replace MODIFY, instead of adding SELECT. This diff fixes this issue.

Test Plan: New unit test. Verified that it failed without the new fix.

Reviewers: oleg, bogdan

Reviewed By: bogdan

Subscribers: kannan, ybase

Differential Revision: https://phabricator.dev.yugabyte.com/D8182
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/docdb YugabyteDB core features kind/bug This issue is a bug priority/high High Priority
Projects
None yet
Development

No branches or pull requests

2 participants