Skip to content

Conversation

@mpenick
Copy link
Contributor

@mpenick mpenick commented May 15, 2020

Fixes: #123

Copy link
Contributor

@jorgebay jorgebay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that in DSE system_schema tables use row-based access control (RLAC). If the user has access to 1 ks, the following queries will return the correct values:

SELECT table_name FROM system_schema.tables WHERE keyspace_name = ?
SELECT * FROM system_schema.keyspaces WHERE  keyspace_name = ?

Given the keyspace the user can access.

If that the case, instead of SELECT COUNT(*) FROM system_schema.keyspaces, we should use SELECT * FROM system_schema.keyspaces WHERE keyspace_name = ? (for single keyspace graphql query) and use system_schema.tables for listing tables.


func (db *Db) ExecuteNoResult(query string, options *QueryOptions, values ...interface{}) error {
return db.session.Execute(query, options, values)
return db.session.Execute(query, options, values...)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch

@mpenick
Copy link
Contributor Author

mpenick commented May 18, 2020

I think that in DSE system_schema tables use row-based access control (RLAC). If the user has access to 1 ks, the following queries will return the correct values:

Oh wow! I didn't know that. Thanks for bringing that up. I'll fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

GraphQL keyspaces to build should consider user or role

3 participants