cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Deleted] (CASSANDRA-8082) Consider re-introducing TRUNCATE permission
Date Thu, 12 Mar 2015 01:35:38 GMT

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

Aleksey Yeschenko updated CASSANDRA-8082:
-----------------------------------------
    Comment: was deleted

(was: Dear sender,

 

I am on a training and be back on Friday 13-03-2015

 

Your email will not be forwarded.

 

Best regards,

Hans van der Linde

 

-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------

)

> Consider re-introducing TRUNCATE permission
> -------------------------------------------
>
>                 Key: CASSANDRA-8082
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8082
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Johnny Miller
>            Priority: Minor
>
> We should consider re-introducing a separate `TRUNCATE` permission.
> Truncate operation would require both `MODIFY` and `TRUNCATE` to run.
> I'm not entirely sold on this change, as we do create snapshots before truncating, so
fat-fingers aren't catastrophic, but am open to the idea.
> Original description:
> {quote}
> Currently CQL permissions are grouped as:
> ALL	- All statements
> ALTER - ALTER KEYSPACE, ALTER TABLE, CREATE INDEX, DROP INDEX
> AUTHORIZE - GRANT, REVOKE
> CREATE - CREATE KEYSPACE, CREATE TABLE
> DROP - DROP KEYSPACE, DROP TABLE
> MODIFY - INSERT, DELETE, UPDATE, TRUNCATE
> SELECT -SELECT
> The MODIFY permission is too wide. There are plenty scenarios where a user should not
be to DELETE and TRUNCATE a table but should be able to INSERT and UPDATE. 
> It would be great if Cassandra could either support defining permissions dynamically
or have additional finer grained MODIFY related permissions.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message