[jira] [Commented] (CASSANDRA-11305) Customization of the auto granting process
[
https://issues.apache.org/jira/browse/CASSANDRA-11305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17360124#comment-17360124
]
Jonathan Koppenhofer commented on CASSANDRA-11305:
--
Reviving this older issue as there are use cases where automatic granting may
not be desired, and potentially break separation of duties concerns. You may
want to allow a user to create a table without having permissions to Authorize
on that table (which is my primary concern). Other concerns people may have is
the nee to keep DDL users separate from users that can actually read/write
data. Also, from a permissions hygiene perspective, if the user already has
keyspace level permissions, they may not want duplicative table level
permissions (can lead to confusion if permissions need revoked).
I like the thoroughness of the original Jira, but I am more inline with simply
being able to turn auto-granting on/off at the yaml level. I'm looking for
feedback on what approach others would like to see.
> Customization of the auto granting process
> --
>
> Key: CASSANDRA-11305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11305
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/CQL
> Environment: Apache Cassandra 3.3, cqlsh 5.0.1, CQL spec 3.4.0
>Reporter: Alexandre Linte
>Priority: Low
> Fix For: 4.x
>
>
> Hello,
> By default, Cassandra implements an auto granting process which is applied
> when a USER | ROLE does a CREATE KEYSPACE, CREATE TABLE, CREATE FUNCTION,
> CREATE AGGREGATE or CREATE ROLE statement. The creator is automatically
> granted all applicable permissions on the new resource.
> For example, the ROLE "toto_user" is created and has CREATE permission on its
> personal KEYSPACE "toto_keyspace". Today when toto_user create a TABLE, he is
> automatically granted the following rights:
> * ALTER
> * DROP
> * SELECT
> * MODIFY
> * AUTHORIZE
> Moreover if you want to REVOKE a permission for "toto_user" on a table, this
> table must exist.
> The idea of the issue is to improve the auto granting process. I thought
> about a modification of the REVOKE and GRANT SQL commands. You can find below
> the syntax part:
> {noformat}
> ::= GRANT ( ALL ( PERMISSIONS )? | (
> PERMISSION )? ) ON TO
> ::= CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE |
> DESRIBE | EXECUTE
> ::= ALL KEYSPACES
> | KEYSPACE
> | ( TABLE )?
> | ALL ROLES
> | ROLE
> | ALL FUNCTIONS ( IN KEYSPACE )?
> | FUNCTION
> ::= WHEN CREATE ( KEYSPACE | TABLE | ROLE )
> {noformat}
> {noformat}
> ::= REVOKE ( ALL ( PERMISSIONS )? | (
> PERMISSION )? ) ON FROM
> ::= CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE |
> DESRIBE | EXECUTE
> ::= ALL KEYSPACES
> | KEYSPACE
> | ( TABLE )?
> | ALL ROLES
> | ROLE
> | ALL FUNCTIONS ( IN KEYSPACE )?
> | FUNCTION
> ::= WHEN CREATE ( KEYSPACE | TABLE | ROLE )
> {noformat}
> And now multiple the samples part:
> {noformat}
> GRANT ALL PERMISSIONS ON KEYSPACE toto_keyspace TO toto_user;
> => default functioning, when toto_user creates a table he will be
> automatically granted all permissions.
> GRANT ALL PERMISSIONS ON KEYSPACE toto_keyspace TO toto_user WHEN CREATE
> TABLE;
> => grant all permissions to the resource (table) created by toto_user on the
> keyspace toto_keyspace.
> GRANT SELECT ON KEYSPACE toto_keyspace TO toto_user WHEN CREATE TABLE;
> => grant select permission to the resource (table) created by toto_user on
> the keyspace toto_keyspace.
> REVOKE ALL PERMISSIONS ON KEYSPACE toto_keyspace FROM toto_user;
> => default functioning, toto_user will not be able to do something on the
> keyspace toto_keyspace.
> REVOKE AUTHORIZE PERMISSION ON KEYSPACE toto_keyspace FROM toto_user WHEN
> CREATE TABLE;
> => revoke authorize permission to the resource (table) created by toto_user
> on the keyspace toto_keyspace.
> REVOKE DROP PERMISSION ALL KEYSPACES FROM toto_user WHEN CREATE ROLE;
> => revoke drop permission to the resource (role) created by toto_user on the
> keyspace toto_keyspace.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11305) Customization of the auto granting process
[
https://issues.apache.org/jira/browse/CASSANDRA-11305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15299940#comment-15299940
]
Sam Tunnicliffe commented on CASSANDRA-11305:
-
bq. Instead of modifying the default CQL behaviour and its semantic (like I
suggested before) maybe this can be implemented throught cassandra.yaml?
maybe, but the Hive config lets you specify exactly which privileges to
automatically grant. I think this is fine for Hive as it only applies to
Databases and Tables, which share the same set of applicable privileges. This
isn't the case in C* though with roles, functions, aggregations and jmx
resources (although the latter are not created in the same way as other
database objects). So if we were to adopt the Hive approach, you'd be
specifying the superset of privileges from which the applicable subset could be
automatically granted and TBH, this feels a bit messy to me.
It might be more feasible to have a single toggle in the yaml to completely
turn off auto granting on a system-wide basis. I did wonder whether a keyspace
level property could work, but not all resources are keyspace-scoped (roles for
instance). I'm not advocating for that system-wide solution btw, just saying
that it seems potentially more straightforward in implementation and conceptual
terms.
I don't see a huge demand for this feature either, so I would imagine it
falling fairly low on the list of priorities I'm afraid, but if you want to
submit a patch for it, please do.
> Customization of the auto granting process
> --
>
> Key: CASSANDRA-11305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11305
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL
> Environment: Apache Cassandra 3.3, cqlsh 5.0.1, CQL spec 3.4.0
>Reporter: Alexandre Linte
>Priority: Minor
> Fix For: 3.3
>
>
> Hello,
> By default, Cassandra implements an auto granting process which is applied
> when a USER | ROLE does a CREATE KEYSPACE, CREATE TABLE, CREATE FUNCTION,
> CREATE AGGREGATE or CREATE ROLE statement. The creator is automatically
> granted all applicable permissions on the new resource.
> For example, the ROLE "toto_user" is created and has CREATE permission on its
> personal KEYSPACE "toto_keyspace". Today when toto_user create a TABLE, he is
> automatically granted the following rights:
> * ALTER
> * DROP
> * SELECT
> * MODIFY
> * AUTHORIZE
> Moreover if you want to REVOKE a permission for "toto_user" on a table, this
> table must exist.
> The idea of the issue is to improve the auto granting process. I thought
> about a modification of the REVOKE and GRANT SQL commands. You can find below
> the syntax part:
> {noformat}
> ::= GRANT ( ALL ( PERMISSIONS )? | (
> PERMISSION )? ) ON TO
> ::= CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE |
> DESRIBE | EXECUTE
> ::= ALL KEYSPACES
> | KEYSPACE
> | ( TABLE )?
> | ALL ROLES
> | ROLE
> | ALL FUNCTIONS ( IN KEYSPACE )?
> | FUNCTION
> ::= WHEN CREATE ( KEYSPACE | TABLE | ROLE )
> {noformat}
> {noformat}
> ::= REVOKE ( ALL ( PERMISSIONS )? | (
> PERMISSION )? ) ON FROM
> ::= CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE |
> DESRIBE | EXECUTE
> ::= ALL KEYSPACES
> | KEYSPACE
> | ( TABLE )?
> | ALL ROLES
> | ROLE
> | ALL FUNCTIONS ( IN KEYSPACE )?
> | FUNCTION
> ::= WHEN CREATE ( KEYSPACE | TABLE | ROLE )
> {noformat}
> And now multiple the samples part:
> {noformat}
> GRANT ALL PERMISSIONS ON KEYSPACE toto_keyspace TO toto_user;
> => default functioning, when toto_user creates a table he will be
> automatically granted all permissions.
> GRANT ALL PERMISSIONS ON KEYSPACE toto_keyspace TO toto_user WHEN CREATE
> TABLE;
> => grant all permissions to the resource (table) created by toto_user on the
> keyspace toto_keyspace.
> GRANT SELECT ON KEYSPACE toto_keyspace TO toto_user WHEN CREATE TABLE;
> => grant select permission to the resource (table) created by toto_user on
> the keyspace toto_keyspace.
> REVOKE ALL PERMISSIONS ON KEYSPACE toto_keyspace FROM toto_user;
> => default functioning, toto_user will not be able to do something on the
> keyspace toto_keyspace.
> REVOKE AUTHORIZE PERMISSION ON KEYSPACE toto_keyspace FROM toto_user WHEN
> CREATE TABLE;
> => revoke authorize permission to the resource (table) created by toto_user
> on the keyspace toto_keyspace.
> REVOKE DROP PERMISSION ALL KEYSPACES FROM toto_user WHEN CREATE ROLE;
> => revoke drop permission to the resource (role) created by toto_user on the
> keyspace toto_keyspace.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332
[jira] [Commented] (CASSANDRA-11305) Customization of the auto granting process
[
https://issues.apache.org/jira/browse/CASSANDRA-11305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15297926#comment-15297926
]
Alexandre Linte commented on CASSANDRA-11305:
-
Hi [~beobal],
Thank you for the feedback. You're right, this is a kind of permission
customization.
The idea is to increase permission's granularity. HBase does something similar
to Cassandra. Hive is also similar but you can specify in the configuration
multiple properties:
- hive.security.authorization.enabled
- hive.security.authorization.manager
- hive.security.authorization.createtable.owner.grants
By default, the creator of a resource has not rights on it. You must set
"hive.security.authorization.createtable.owner.grants".
Instead of modifying the default CQL behaviour and its semantic (like I
suggested before) maybe this can be implemented throught cassandra.yaml?
> Customization of the auto granting process
> --
>
> Key: CASSANDRA-11305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11305
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL
> Environment: Apache Cassandra 3.3, cqlsh 5.0.1, CQL spec 3.4.0
>Reporter: Alexandre Linte
>Priority: Minor
> Fix For: 3.3
>
>
> Hello,
> By default, Cassandra implements an auto granting process which is applied
> when a USER | ROLE does a CREATE KEYSPACE, CREATE TABLE, CREATE FUNCTION,
> CREATE AGGREGATE or CREATE ROLE statement. The creator is automatically
> granted all applicable permissions on the new resource.
> For example, the ROLE "toto_user" is created and has CREATE permission on its
> personal KEYSPACE "toto_keyspace". Today when toto_user create a TABLE, he is
> automatically granted the following rights:
> * ALTER
> * DROP
> * SELECT
> * MODIFY
> * AUTHORIZE
> Moreover if you want to REVOKE a permission for "toto_user" on a table, this
> table must exist.
> The idea of the issue is to improve the auto granting process. I thought
> about a modification of the REVOKE and GRANT SQL commands. You can find below
> the syntax part:
> {noformat}
> ::= GRANT ( ALL ( PERMISSIONS )? | (
> PERMISSION )? ) ON TO
> ::= CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE |
> DESRIBE | EXECUTE
> ::= ALL KEYSPACES
> | KEYSPACE
> | ( TABLE )?
> | ALL ROLES
> | ROLE
> | ALL FUNCTIONS ( IN KEYSPACE )?
> | FUNCTION
> ::= WHEN CREATE ( KEYSPACE | TABLE | ROLE )
> {noformat}
> {noformat}
> ::= REVOKE ( ALL ( PERMISSIONS )? | (
> PERMISSION )? ) ON FROM
> ::= CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE |
> DESRIBE | EXECUTE
> ::= ALL KEYSPACES
> | KEYSPACE
> | ( TABLE )?
> | ALL ROLES
> | ROLE
> | ALL FUNCTIONS ( IN KEYSPACE )?
> | FUNCTION
> ::= WHEN CREATE ( KEYSPACE | TABLE | ROLE )
> {noformat}
> And now multiple the samples part:
> {noformat}
> GRANT ALL PERMISSIONS ON KEYSPACE toto_keyspace TO toto_user;
> => default functioning, when toto_user creates a table he will be
> automatically granted all permissions.
> GRANT ALL PERMISSIONS ON KEYSPACE toto_keyspace TO toto_user WHEN CREATE
> TABLE;
> => grant all permissions to the resource (table) created by toto_user on the
> keyspace toto_keyspace.
> GRANT SELECT ON KEYSPACE toto_keyspace TO toto_user WHEN CREATE TABLE;
> => grant select permission to the resource (table) created by toto_user on
> the keyspace toto_keyspace.
> REVOKE ALL PERMISSIONS ON KEYSPACE toto_keyspace FROM toto_user;
> => default functioning, toto_user will not be able to do something on the
> keyspace toto_keyspace.
> REVOKE AUTHORIZE PERMISSION ON KEYSPACE toto_keyspace FROM toto_user WHEN
> CREATE TABLE;
> => revoke authorize permission to the resource (table) created by toto_user
> on the keyspace toto_keyspace.
> REVOKE DROP PERMISSION ALL KEYSPACES FROM toto_user WHEN CREATE ROLE;
> => revoke drop permission to the resource (role) created by toto_user on the
> keyspace toto_keyspace.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11305) Customization of the auto granting process
[
https://issues.apache.org/jira/browse/CASSANDRA-11305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15296110#comment-15296110
]
Sam Tunnicliffe commented on CASSANDRA-11305:
-
What's the use case you're trying to satisfy here? It seems like the goal is to
provide some sort of customisation to the automatic granting, so that you can
do things like only have certain permissions automatically granted. But I have
to say I'm not really a fan of this as it makes things harder to reason about
and that is generally something to be avoided in security.
I also think that working around/with the default behaviour (which we would
definitely want to preserve) makes things more problematic. For instance, if
you want to make it so {{toto_user}} only gets {{SELECT}} permissions on any
table that they create you'd need to execute all three statements (in the
correct order):
{code}
REVOKE ALL PERMISSIONS ON KEYSPACE toto_keyspace FROM toto_user;
GRANT CREATE ON KEYSPACE toto_keyspace TO toto_user; // so table creation is
possible
GRANT SELECT ON KEYSPACE toto_keyspace TO toto_user WHEN CREATE TABLE;
{code}
which is itself quite unintuitive. To be honest, if you need to be able to have
the grants configurable on a per-user basis, that's probably something that
belongs externally, not in the core db functionality.
> Customization of the auto granting process
> --
>
> Key: CASSANDRA-11305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11305
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL
> Environment: Apache Cassandra 3.3, cqlsh 5.0.1, CQL spec 3.4.0
>Reporter: Alexandre Linte
>Priority: Minor
> Fix For: 3.3
>
>
> Hello,
> By default, Cassandra implements an auto granting process which is applied
> when a USER | ROLE does a CREATE KEYSPACE, CREATE TABLE, CREATE FUNCTION,
> CREATE AGGREGATE or CREATE ROLE statement. The creator is automatically
> granted all applicable permissions on the new resource.
> For example, the ROLE "toto_user" is created and has CREATE permission on its
> personal KEYSPACE "toto_keyspace". Today when toto_user create a TABLE, he is
> automatically granted the following rights:
> * ALTER
> * DROP
> * SELECT
> * MODIFY
> * AUTHORIZE
> Moreover if you want to REVOKE a permission for "toto_user" on a table, this
> table must exist.
> The idea of the issue is to improve the auto granting process. I thought
> about a modification of the REVOKE and GRANT SQL commands. You can find below
> the syntax part:
> {noformat}
> ::= GRANT ( ALL ( PERMISSIONS )? | (
> PERMISSION )? ) ON TO
> ::= CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE |
> DESRIBE | EXECUTE
> ::= ALL KEYSPACES
> | KEYSPACE
> | ( TABLE )?
> | ALL ROLES
> | ROLE
> | ALL FUNCTIONS ( IN KEYSPACE )?
> | FUNCTION
> ::= WHEN CREATE ( KEYSPACE | TABLE | ROLE )
> {noformat}
> {noformat}
> ::= REVOKE ( ALL ( PERMISSIONS )? | (
> PERMISSION )? ) ON FROM
> ::= CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE |
> DESRIBE | EXECUTE
> ::= ALL KEYSPACES
> | KEYSPACE
> | ( TABLE )?
> | ALL ROLES
> | ROLE
> | ALL FUNCTIONS ( IN KEYSPACE )?
> | FUNCTION
> ::= WHEN CREATE ( KEYSPACE | TABLE | ROLE )
> {noformat}
> And now multiple the samples part:
> {noformat}
> GRANT ALL PERMISSIONS ON KEYSPACE toto_keyspace TO toto_user;
> => default functioning, when toto_user creates a table he will be
> automatically granted all permissions.
> GRANT ALL PERMISSIONS ON KEYSPACE toto_keyspace TO toto_user WHEN CREATE
> TABLE;
> => grant all permissions to the resource (table) created by toto_user on the
> keyspace toto_keyspace.
> GRANT SELECT ON KEYSPACE toto_keyspace TO toto_user WHEN CREATE TABLE;
> => grant select permission to the resource (table) created by toto_user on
> the keyspace toto_keyspace.
> REVOKE ALL PERMISSIONS ON KEYSPACE toto_keyspace FROM toto_user;
> => default functioning, toto_user will not be able to do something on the
> keyspace toto_keyspace.
> REVOKE AUTHORIZE PERMISSION ON KEYSPACE toto_keyspace FROM toto_user WHEN
> CREATE TABLE;
> => revoke authorize permission to the resource (table) created by toto_user
> on the keyspace toto_keyspace.
> REVOKE DROP PERMISSION ALL KEYSPACES FROM toto_user WHEN CREATE ROLE;
> => revoke drop permission to the resource (role) created by toto_user on the
> keyspace toto_keyspace.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11305) Customization of the auto granting process
[
https://issues.apache.org/jira/browse/CASSANDRA-11305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290731#comment-15290731
]
Alexandre Linte commented on CASSANDRA-11305:
-
Nothing new about this JIRA?
> Customization of the auto granting process
> --
>
> Key: CASSANDRA-11305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11305
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL
> Environment: Apache Cassandra 3.3, cqlsh 5.0.1, CQL spec 3.4.0
>Reporter: Alexandre Linte
>Priority: Minor
> Fix For: 3.3
>
>
> Hello,
> By default, Cassandra implements an auto granting process which is applied
> when a USER | ROLE does a CREATE KEYSPACE, CREATE TABLE, CREATE FUNCTION,
> CREATE AGGREGATE or CREATE ROLE statement. The creator is automatically
> granted all applicable permissions on the new resource.
> For example, the ROLE "toto_user" is created and has CREATE permission on its
> personal KEYSPACE "toto_keyspace". Today when toto_user create a TABLE, he is
> automatically granted the following rights:
> * ALTER
> * DROP
> * SELECT
> * MODIFY
> * AUTHORIZE
> Moreover if you want to REVOKE a permission for "toto_user" on a table, this
> table must exist.
> The idea of the issue is to improve the auto granting process. I thought
> about a modification of the REVOKE and GRANT SQL commands. You can find below
> the syntax part:
> {noformat}
> ::= GRANT ( ALL ( PERMISSIONS )? | (
> PERMISSION )? ) ON TO
> ::= CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE |
> DESRIBE | EXECUTE
> ::= ALL KEYSPACES
> | KEYSPACE
> | ( TABLE )?
> | ALL ROLES
> | ROLE
> | ALL FUNCTIONS ( IN KEYSPACE )?
> | FUNCTION
> ::= WHEN CREATE ( KEYSPACE | TABLE | ROLE )
> {noformat}
> {noformat}
> ::= REVOKE ( ALL ( PERMISSIONS )? | (
> PERMISSION )? ) ON FROM
> ::= CREATE | ALTER | DROP | SELECT | MODIFY | AUTHORIZE |
> DESRIBE | EXECUTE
> ::= ALL KEYSPACES
> | KEYSPACE
> | ( TABLE )?
> | ALL ROLES
> | ROLE
> | ALL FUNCTIONS ( IN KEYSPACE )?
> | FUNCTION
> ::= WHEN CREATE ( KEYSPACE | TABLE | ROLE )
> {noformat}
> And now multiple the samples part:
> {noformat}
> GRANT ALL PERMISSIONS ON KEYSPACE toto_keyspace TO toto_user;
> => default functioning, when toto_user creates a table he will be
> automatically granted all permissions.
> GRANT ALL PERMISSIONS ON KEYSPACE toto_keyspace TO toto_user WHEN CREATE
> TABLE;
> => grant all permissions to the resource (table) created by toto_user on the
> keyspace toto_keyspace.
> GRANT SELECT ON KEYSPACE toto_keyspace TO toto_user WHEN CREATE TABLE;
> => grant select permission to the resource (table) created by toto_user on
> the keyspace toto_keyspace.
> REVOKE ALL PERMISSIONS ON KEYSPACE toto_keyspace FROM toto_user;
> => default functioning, toto_user will not be able to do something on the
> keyspace toto_keyspace.
> REVOKE AUTHORIZE PERMISSION ON KEYSPACE toto_keyspace FROM toto_user WHEN
> CREATE TABLE;
> => revoke authorize permission to the resource (table) created by toto_user
> on the keyspace toto_keyspace.
> REVOKE DROP PERMISSION ALL KEYSPACES FROM toto_user WHEN CREATE ROLE;
> => revoke drop permission to the resource (role) created by toto_user on the
> keyspace toto_keyspace.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
