[jira] [Comment Edited] (CASSANDRA-12859) Column-level permissions
[
https://issues.apache.org/jira/browse/CASSANDRA-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15729145#comment-15729145
]
Boris Melamed edited comment on CASSANDRA-12859 at 12/7/16 4:36 PM:
Please review, the commits are:
On my C* trunk fork:
https://github.com/bmel/cassandra/commit/4a584dac44e15bff6757121bb39bd9c59e8d5131
On my dtest fork:
https://github.com/bmel/cassandra-dtest/commit/360b44630070481afb1ef1bd4623700f446782eb
These are on feature branches, named 'col-perms-12859' in both projects.
I thought to only create pull requests after an initial review.
Let me know if you'd like me to create pull requests already - in which case
I'll also pull the trunk/master changes from the past month, into my branch...
was (Author: bmel):
Please review, the commits are:
On my C* trunk fork:
https://github.com/bmel/cassandra/commit/4a584dac44e15bff6757121bb39bd9c59e8d5131
On my dtest fork:
https://github.com/bmel/cassandra-dtest/commit/360b44630070481afb1ef1bd4623700f446782eb
These are on feature branches, named 'col-perms-12859' in both projects.
I thought to only create pull requests after an initial review.
Let me know if you'd like me to create pull requests already.
> Column-level permissions
>
>
> Key: CASSANDRA-12859
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12859
> Project: Cassandra
> Issue Type: New Feature
> Components: Core, CQL
>Reporter: Boris Melamed
> Labels: doc-impacting
> Attachments: Cassandra Proposal - Column-level permissions v2.docx,
> Cassandra Proposal - Column-level permissions.docx
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> h4. Here is a draft of:
> Cassandra Proposal - Column-level permissions.docx (attached)
> h4. Quoting the 'Overview' section:
> The purpose of this proposal is to add column-level (field-level) permissions
> to Cassandra. It is my intent to soon start implementing this feature in a
> fork, and to submit a pull request once it’s ready.
> h4. Motivation
> Cassandra already supports permissions on keyspace and table (column family)
> level. Sources:
> * http://www.datastax.com/dev/blog/role-based-access-control-in-cassandra
> * https://cassandra.apache.org/doc/latest/cql/security.html#data-control
> At IBM, we have use cases in the area of big data analytics where
> column-level access permissions are also a requirement. All industry RDBMS
> products are supporting this level of permission control, and regulators are
> expecting it from all data-based systems.
> h4. Main day-one requirements
> # Extend CQL (Cassandra Query Language) to be able to optionally specify a
> list of individual columns, in the {{GRANT}} statement. The relevant
> permission types are: {{MODIFY}} (for {{UPDATE}} and {{INSERT}}) and
> {{SELECT}}.
> # Persist the optional information in the appropriate system table
> ‘system_auth.role_permissions’.
> # Enforce the column access restrictions during execution. Details:
> #* Should fit with the existing permission propagation down a role chain.
> #* Proposed message format when a user’s roles give access to the queried
> table but not to all of the selected, inserted, or updated columns:
> "User %s has no %s permission on column %s of table %s"
> #* Error will report only the first checked column.
> Nice to have: list all inaccessible columns.
> #* Error code is the same as for table access denial: 2100.
> h4. Additional day-one requirements
> # Reflect the column-level permissions in statements of type
> {{LIST ALL PERMISSIONS OF someuser;}}
> # When columns are dropped or renamed, trigger purging or adapting of their
> permissions
> # Performance should not degrade in any significant way.
> # Backwards compatibility
> #* Permission enforcement for DBs created before the upgrade should continue
> to work with the same behavior after upgrading to a version that allows
> column-level permissions.
> #* Previous CQL syntax will remain valid, and have the same effect as before.
> h4. Documentation
> *
> https://cassandra.apache.org/doc/latest/cql/security.html#grammar-token-permission
> * Feedback request: any others?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-12859) Column-level permissions
[
https://issues.apache.org/jira/browse/CASSANDRA-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15728964#comment-15728964
]
Jeremiah Jordan edited comment on CASSANDRA-12859 at 12/7/16 3:06 PM:
--
This should work like tables and keyspaces work.
If I grant access to ks1 then revoke ks1.t1 what happens? The same thing that
happens for that should happen for grant access to ks1.t1 then revoke access to
ks1.t1.c1.
The same should be true for the other cases described as well.
I think it should be required for grant and revoke to work in a complementary
fashion in v1 of this. So either grant replaces and revoke removes all. Or
grant is additive and revoke is subtractive. If this is not how it works then
it is impossible to remove access to a column without having an outage for an
application that has stopped using said column.
GRANT SELECT(c1,c2,c3) ON ks1.t1 TO r1;
Application usIng r1 never uses c3 so you decide to revoke access to that.
In order to not disrupt the application you need to be able to do that in one
command. Either
GRANT SELECT(c1,c2) ON ks1.t1 TO r1;
To overwrite the old columns. Or
REVOKE SELECT(c1) ON ks1.t1
Also given that this is basically adding a 3rd level to the hierarchy should we
actually grant a single column at a time and make it GRANT SELECT ON ks1.t1.c1
TO r1? Then we don't have to worry about the "()" stuff being valid, it is
just adding a 3rd level to the data resource hierarchy.
was (Author: jjordan):
This should work like tables and keyspaces work.
If I can't access to ks1 then revoke ks1.t1 what happens? The same thing that
happens for that should happen for grant access to ks1.t1 then revoke access to
ks1.t1.c1.
The same should be true for the other cases described as well.
I think it should be required for grant and revoke to work in a complementary
fashion in v1 of this. So either grant replaces and revoke removes all. Or
grant is additive and revoke is subtractive. If this is not how it works then
it is impossible to remove access to a column without having an outage for an
application that has stopped using said column.
GRANT SELECT(c1,c2,c3) ON ks1.t1 TO r1;
Application usIng r1 never uses c3 so you decide to revoke access to that.
In order to not disrupt the application you need to be able to do that in one
command. Either
GRANT SELECT(c1,c2) ON ks1.t1 TO r1;
To overwrite the old columns. Or
REVOKE SELECT(c1) ON ks1.t1
Also given that this is basically adding a 3rd level to the hierarchy should we
actually grant a single column at a time and make it GRANT SELECT ON ks1.t1.c1
TO r1? Then we don't have to worry about the "()" stuff being valid, it is
just adding a 3rd level to the data resource hierarchy.
> Column-level permissions
>
>
> Key: CASSANDRA-12859
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12859
> Project: Cassandra
> Issue Type: New Feature
> Components: Core, CQL
>Reporter: Boris Melamed
> Labels: doc-impacting
> Attachments: Cassandra Proposal - Column-level permissions v2.docx,
> Cassandra Proposal - Column-level permissions.docx
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> h4. Here is a draft of:
> Cassandra Proposal - Column-level permissions.docx (attached)
> h4. Quoting the 'Overview' section:
> The purpose of this proposal is to add column-level (field-level) permissions
> to Cassandra. It is my intent to soon start implementing this feature in a
> fork, and to submit a pull request once it’s ready.
> h4. Motivation
> Cassandra already supports permissions on keyspace and table (column family)
> level. Sources:
> * http://www.datastax.com/dev/blog/role-based-access-control-in-cassandra
> * https://cassandra.apache.org/doc/latest/cql/security.html#data-control
> At IBM, we have use cases in the area of big data analytics where
> column-level access permissions are also a requirement. All industry RDBMS
> products are supporting this level of permission control, and regulators are
> expecting it from all data-based systems.
> h4. Main day-one requirements
> # Extend CQL (Cassandra Query Language) to be able to optionally specify a
> list of individual columns, in the {{GRANT}} statement. The relevant
> permission types are: {{MODIFY}} (for {{UPDATE}} and {{INSERT}}) and
> {{SELECT}}.
> # Persist the optional information in the appropriate system table
> ‘system_auth.role_permissions’.
> # Enforce the column access restrictions during execution. Details:
> #* Should fit with the existing permission propagation down a role chain.
> #* Proposed message format when a user’s roles give access to the queried
> table but not to all of the selected, inserted, or updated columns:
> "User %s has no %s permission on column %s of table %s"
> #* Error
[jira] [Comment Edited] (CASSANDRA-12859) Column-level permissions
[ https://issues.apache.org/jira/browse/CASSANDRA-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15728783#comment-15728783 ] Boris Melamed edited comment on CASSANDRA-12859 at 12/7/16 1:40 PM: Arguably, this is the ultimate goal. Yet actually, the REVOKE direction is as user-unfriendly as initially planned, after the above discussions, for both GRANT and REVOKE. But at least GRANT is now more user-friendly than that. In therms of coding, it's not a big effort to make REVOKE subtractive. For now, would you agree to add the current functionality (pending review) to the trunk, or do you consider this an 'all or nothing' situation? Moreover, making REVOKE subtractive opens a can of worms. As background, please see section "Some details on permission lifecycle and precedence" in the attached 'v2' document. Consider these potentially confusing cases, especially #2: 1. Last column gets subtracted * GRANT SELECT(c1, c2) ON ks.t1 TO Joe; -- Joe can select c1 and c2 from t1 * REVOKE SELECT(c2) ON ks.t1 FROM Joe; -- Joe can select only c1 from t1 * REVOKE SELECT(c1) ON ks.t1 FROM Joe; -- What now? After the last command, should Joe have access to all of t1, or should his access to t1 get revoked altogether? I'm guessing the latter, but would like this confirmed. 2. Subtracting a column that had not been added * GRANT SELECT ON ks.t1 TO Joe; -- Joe can select all of t1 * REVOKE SELECT(c2) ON ks.t1 FROM Joe; -- What now? After the REVOKE, should Joe have access to all of t1's columns except for c2? This might be a natural expectation. However, we're not planning on introducing black lists. We could 'fake it' by restricting the permission to all columns except for c2, equivalent to (informally): * GRANT SELECT(c1,c3,c4,...) ON ks.t1 TO Joe; -- Joe can select all of t1 except for c2 But then, Joe would not be able to access columns that got added afterwards. So I would suggest that revoking columns that are not in the current permission constraint should have no effect on permissions. But this may not follow a user's intuition, and needs to be clearly documented. In any case, I'm guessing that these other tasks should be the next in line, before column-level permissions can get into the product: * LIST PERMISSIONS * Purging of column constraints after dropping columns was (Author: bmel): Arguably, this is the ultimate goal. Yet actually, the REVOKE direction is as user-unfriendly as initially planned, after the above discussions, for both GRANT and REVOKE. But at least GRANT is now more user-friendly than that. In therms of coding, it's not a big effort to make REVOKE subtractive. For now, would you agree to add the current functionality (pending review) to the trunk, or do you consider this an 'all or nothing' situation? Moreover, making REVOKE subtractive opens a can of worms. As background, please see section "Some details on permission lifecycle and precedence" in the attached 'v2' document. Consider these potentially confusing cases, especially #2: 1. Last column gets subtracted * GRANT SELECT(c1, c2) ON ks.t1 TO Joe; -- Joe can select c1 and c2 from t1 * REVOKE SELECT(c2) ON ks.t1 FROM Joe; -- Joe can select only c1 from t1 * REVOKE SELECT(c1) ON ks.t1 FROM Joe; -- What now? After the last command, should Joe have access to all of t1, or should his access to t1 get revoked altogether? I'm guessing the latter, but would like this confirmed. 2. Subtracting a column that had not been added * GRANT SELECT ON ks.t1 TO Joe; -- Joe can select all of t1 * REVOKE SELECT(c2) ON ks.t1 FROM Joe; -- What now? After the REVOKE, should Joe have access to all of t1's columns except for c2? This might be a natural expectation. However, we're not planning on introducing black lists. We could 'fake it' by restricting the permission to all columns except for c2, equivalent to (informally): * GRANT SELECT(c1,c3,c4,...) ON ks.t1 TO Joe; -- Joe can select all of t1 except for c2 But then, Joe would not be able to access columns that got added afterwards. So I would suggest that revoking columns that are not in the current permission constraint should have no effect on permissions. But this may not follow a user's intuition, and needs to be clearly documented. In any case, I'm guessing that these other tasks should be the next in line, before this feature can get into the product: * LIST PERMISSIONS * Purging of column constraints after dropping columns > Column-level permissions > > > Key: CASSANDRA-12859 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12859 > Project: Cassandra > Issue Type: New Feature > Components: Core, CQL >Reporter: Boris Melamed > Labels: doc-impacting > Attachments: Cassandra Proposal - Column-level permissions v2.docx, >
[jira] [Comment Edited] (CASSANDRA-12859) Column-level permissions
[ https://issues.apache.org/jira/browse/CASSANDRA-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15728783#comment-15728783 ] Boris Melamed edited comment on CASSANDRA-12859 at 12/7/16 1:37 PM: Arguably, this is the ultimate goal. Yet actually, the REVOKE direction is as user-unfriendly as initially planned, after the above discussions, for both GRANT and REVOKE. But at least GRANT is now more user-friendly than that. In therms of coding, it's not a big effort to make REVOKE subtractive. For now, would you agree to add the current functionality (pending review) to the trunk, or do you consider this an 'all or nothing' situation? Moreover, making REVOKE subtractive opens a can of worms. As background, please see section "Some details on permission lifecycle and precedence" in the attached 'v2' document. Consider these potentially confusing cases, especially #2: 1. Last column gets subtracted * GRANT SELECT(c1, c2) ON ks.t1 TO Joe; -- Joe can select c1 and c2 from t1 * REVOKE SELECT(c2) ON ks.t1 FROM Joe; -- Joe can select only c1 from t1 * REVOKE SELECT(c1) ON ks.t1 FROM Joe; -- What now? After the last command, should Joe have access to all of t1, or should his access to t1 get revoked altogether? I'm guessing the latter, but would like this confirmed. 2. Subtracting a column that had not been added * GRANT SELECT ON ks.t1 TO Joe; -- Joe can select all of t1 * REVOKE SELECT(c2) ON ks.t1 FROM Joe; -- What now? After the REVOKE, should Joe have access to all of t1's columns except for c2? This might be a natural expectation. However, we're not planning on introducing black lists. We could 'fake it' by restricting the permission to all columns except for c2, equivalent to (informally): * GRANT SELECT(c1,c3,c4,...) ON ks.t1 TO Joe; -- Joe can select all of t1 except for c2 But then, Joe would not be able to access columns that got added afterwards. So I would suggest that revoking columns that are not in the current permission constraint should have no effect on permissions. But this may not follow a user's intuition, and needs to be clearly documented. In any case, I'm guessing that these other tasks should be the next in line, before this feature can get into the product: * LIST PERMISSIONS * Purging of column constraints after dropping columns was (Author: bmel): Arguably, this is the ultimate goal. Yet actually, the REVOKE direction is as user-unfriendly as initially planned, after the above discussions, for both GRANT and REVOKE. But at least GRANT is now more user-friendly than that. In therms of coding, it's not a big effort to make REVOKE subtractive. For now, would you agree to add the current functionality (pending review) to the trunk, or do you consider this an 'all or nothing' situation? Moreover, making REVOKE subtractive opens a can of worms. As background, please see section "Some details on permission lifecycle and precedence" in the attached 'v2' document. Consider these potentially confusing cases, especially #2: 1. Last column gets subtracted ** GRANT SELECT(c1, c2) ON ks.t1 TO Joe; -- Joe can select c1 and c2 from t1 ** REVOKE SELECT(c2) ON ks.t1 FROM Joe; -- Joe can select only c1 from t1 ** REVOKE SELECT(c1) ON ks.t1 FROM Joe; -- What now? After the last command, should Joe have access to all of t1, or should his access to t1 get revoked altogether? I'm guessing the latter, but would like this confirmed. 2. Subtracting a column that had not been added ** GRANT SELECT ON ks.t1 TO Joe; -- Joe can select all of t1 ** REVOKE SELECT(c2) ON ks.t1 FROM Joe; -- What now? After the REVOKE, should Joe have access to all of t1's columns except for c2? This might be a natural expectation. However, we're not planning on introducing black lists. We could 'fake it' by restricting the permission to all columns except for c2, equivalent to (informally): ** GRANT SELECT(c1,c3,c4,...) ON ks.t1 TO Joe; -- Joe can select all of t1 except for c2 But then, Joe would not be able to access columns that got added afterwards. So I would suggest that revoking columns that are not in the current permission constraint should have no effect on permissions. But this may not follow a user's intuition, and needs to be clearly documented. In any case, I'm guessing that these other tasks should be the next in line, before this feature can get into the product: * LIST PERMISSIONS * Purging of column constraints after dropping columns > Column-level permissions > > > Key: CASSANDRA-12859 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12859 > Project: Cassandra > Issue Type: New Feature > Components: Core, CQL >Reporter: Boris Melamed > Labels: doc-impacting > Attachments: Cassandra Proposal - Column-level permissions v2.docx, > Cassandra
[jira] [Comment Edited] (CASSANDRA-12859) Column-level permissions
[
https://issues.apache.org/jira/browse/CASSANDRA-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15725984#comment-15725984
]
Boris Melamed edited comment on CASSANDRA-12859 at 12/6/16 4:36 PM:
I've got a working implementation with unit tests and dtests.
Planning to prepare a clean commit for review, by tomorrow.
Still to do, at this stage:
Testing:
- A few more tests (special chars in columns names, MVs)
Implementation and testing:
- LIST PERMISSIONS.
- Purging of column constraints after dropping columns.
was (Author: bmel):
I've got a working implementation with unit tests and dtests.
Planning to prepare a clean commit for review, by tomorrow.
Still to do, at this stage:
Testing:
- A few more tests (special chars in columns names, MVs)
Implementation and testing:
- LIST PERMISSIONS.
- Purging of column constraints after dropping columns.
> Column-level permissions
>
>
> Key: CASSANDRA-12859
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12859
> Project: Cassandra
> Issue Type: New Feature
> Components: Core, CQL
>Reporter: Boris Melamed
> Labels: doc-impacting
> Attachments: Cassandra Proposal - Column-level permissions v2.docx,
> Cassandra Proposal - Column-level permissions.docx
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> h4. Here is a draft of:
> Cassandra Proposal - Column-level permissions.docx (attached)
> h4. Quoting the 'Overview' section:
> The purpose of this proposal is to add column-level (field-level) permissions
> to Cassandra. It is my intent to soon start implementing this feature in a
> fork, and to submit a pull request once it’s ready.
> h4. Motivation
> Cassandra already supports permissions on keyspace and table (column family)
> level. Sources:
> * http://www.datastax.com/dev/blog/role-based-access-control-in-cassandra
> * https://cassandra.apache.org/doc/latest/cql/security.html#data-control
> At IBM, we have use cases in the area of big data analytics where
> column-level access permissions are also a requirement. All industry RDBMS
> products are supporting this level of permission control, and regulators are
> expecting it from all data-based systems.
> h4. Main day-one requirements
> # Extend CQL (Cassandra Query Language) to be able to optionally specify a
> list of individual columns, in the {{GRANT}} statement. The relevant
> permission types are: {{MODIFY}} (for {{UPDATE}} and {{INSERT}}) and
> {{SELECT}}.
> # Persist the optional information in the appropriate system table
> ‘system_auth.role_permissions’.
> # Enforce the column access restrictions during execution. Details:
> #* Should fit with the existing permission propagation down a role chain.
> #* Proposed message format when a user’s roles give access to the queried
> table but not to all of the selected, inserted, or updated columns:
> "User %s has no %s permission on column %s of table %s"
> #* Error will report only the first checked column.
> Nice to have: list all inaccessible columns.
> #* Error code is the same as for table access denial: 2100.
> h4. Additional day-one requirements
> # Reflect the column-level permissions in statements of type
> {{LIST ALL PERMISSIONS OF someuser;}}
> # When columns are dropped or renamed, trigger purging or adapting of their
> permissions
> # Performance should not degrade in any significant way.
> # Backwards compatibility
> #* Permission enforcement for DBs created before the upgrade should continue
> to work with the same behavior after upgrading to a version that allows
> column-level permissions.
> #* Previous CQL syntax will remain valid, and have the same effect as before.
> h4. Documentation
> *
> https://cassandra.apache.org/doc/latest/cql/security.html#grammar-token-permission
> * Feedback request: any others?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-12859) Column-level permissions
[
https://issues.apache.org/jira/browse/CASSANDRA-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15725956#comment-15725956
]
Boris Melamed edited comment on CASSANDRA-12859 at 12/6/16 4:26 PM:
I've attached an updated solution doc:
https://issues.apache.org/jira/secure/attachment/12841986/Cassandra%20Proposal%20-%20Column-level%20permissions%20v2.docx
All changes are tracked, for easier review.
Main changes and decisions since v0.1:
1. Incorporated feedback from Sam Tunnicliffe: DELETE/TRUNCATE, cleanup,
unit tests, ...
2. Added a clarifying section "Some details on permission lifecycle and
precedence" to "Overview".
3. Regarding grammar of GRANT, opted for (A), the more standard 'GRANT
SELECT(c1, c2) ON ks.t1 TO role1'.
4. Slight modification to persisting column sets, see Option B' on page 8.
5. Granting permissions on columns is additive, not replacing. This may
indeed be more intuitive. For now, however, one cannot specify columns on
REVOKE. Therefore, the only way to revoke a column permission is to revoke that
permission on the whole table and then to grant the permission on the
previously included columns except c1.
was (Author: bmel):
All changes are tracked, for easier review.
Main changes and decisions since v0.1:
1. Incorporated feedback from Sam Tunnicliffe: DELETE/TRUNCATE, cleanup,
unit tests, ...
2. Added a clarifying section "Some details on permission lifecycle and
precedence" to "Overview".
3. Regarding grammar of GRANT, opted for (A), the more standard 'GRANT
SELECT(c1, c2) ON ks.t1 TO role1'.
4. Slight modification to persisting column sets, see Option B' on page 8.
5. Granting permissions on columns is additive, not replacing. This may
indeed be more intuitive. For now, however, one cannot specify columns on
REVOKE. Therefore, the only way to revoke a column permission is to revoke that
permission on the whole table and then to grant the permission on the
previously included columns except c1.
> Column-level permissions
>
>
> Key: CASSANDRA-12859
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12859
> Project: Cassandra
> Issue Type: New Feature
> Components: Core, CQL
>Reporter: Boris Melamed
> Labels: doc-impacting
> Attachments: Cassandra Proposal - Column-level permissions v2.docx,
> Cassandra Proposal - Column-level permissions.docx
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> h4. Here is a draft of:
> Cassandra Proposal - Column-level permissions.docx (attached)
> h4. Quoting the 'Overview' section:
> The purpose of this proposal is to add column-level (field-level) permissions
> to Cassandra. It is my intent to soon start implementing this feature in a
> fork, and to submit a pull request once it’s ready.
> h4. Motivation
> Cassandra already supports permissions on keyspace and table (column family)
> level. Sources:
> * http://www.datastax.com/dev/blog/role-based-access-control-in-cassandra
> * https://cassandra.apache.org/doc/latest/cql/security.html#data-control
> At IBM, we have use cases in the area of big data analytics where
> column-level access permissions are also a requirement. All industry RDBMS
> products are supporting this level of permission control, and regulators are
> expecting it from all data-based systems.
> h4. Main day-one requirements
> # Extend CQL (Cassandra Query Language) to be able to optionally specify a
> list of individual columns, in the {{GRANT}} statement. The relevant
> permission types are: {{MODIFY}} (for {{UPDATE}} and {{INSERT}}) and
> {{SELECT}}.
> # Persist the optional information in the appropriate system table
> ‘system_auth.role_permissions’.
> # Enforce the column access restrictions during execution. Details:
> #* Should fit with the existing permission propagation down a role chain.
> #* Proposed message format when a user’s roles give access to the queried
> table but not to all of the selected, inserted, or updated columns:
> "User %s has no %s permission on column %s of table %s"
> #* Error will report only the first checked column.
> Nice to have: list all inaccessible columns.
> #* Error code is the same as for table access denial: 2100.
> h4. Additional day-one requirements
> # Reflect the column-level permissions in statements of type
> {{LIST ALL PERMISSIONS OF someuser;}}
> # When columns are dropped or renamed, trigger purging or adapting of their
> permissions
> # Performance should not degrade in any significant way.
> # Backwards compatibility
> #* Permission enforcement for DBs created before the upgrade should continue
> to work with the same behavior after upgrading to a version that allows
> column-level permissions.
> #* Previous CQL syntax will remain valid, and have
[jira] [Comment Edited] (CASSANDRA-12859) Column-level permissions
[
https://issues.apache.org/jira/browse/CASSANDRA-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15625503#comment-15625503
]
Boris Melamed edited comment on CASSANDRA-12859 at 11/1/16 2:33 PM:
Thank you, that would indeed fit nicely.
Here is a slightly modified example, to illustrate the difference between
required permissions. I'm mentioning PK columns in the required permissions,
just as other columns.
{code}
// Table schema definition:
CREATE ks.t1 (p int, c int, v int, w int, PRIMARY KEY (p,c));
// Accessing individual columns:
INSERT INTO ks.t1(p, c, v) VALUES (0, 0, 0); // requires MODIFY on at least
ks.t1(p, c, v)
SELECT v FROM ks.t1 WHERE p = 0 AND c = 0; // requires SELECT on at least
ks.t1(p, c, v)
UPDATE ks.t1 SET v = 1 WHERE p = 0 AND c = 0; // requires MODIFY on at least
ks.t1(p, c, v)
DELETE v FROM ks.t1 WHERE p = 0 AND c = 0; // requires MODIFY on at least
ks.t1(p, c, v)
// Accessing whole rows (all columns):
SELECT * FROM ks.t1 WHERE p = 0 AND c = 0; // requires SELECT on at least
ks.t1(p, c, v, w)
DELETE FROM ks.t1 WHERE p = 0 AND c = 0; // requires MODIFY on at least
ks.t1(p, c, v, w)
TRUNCATE ks.t1; // requires MODIFY on at least
ks.t1(p, c, v, w)
{code}
was (Author: bmel):
Thank you, that would indeed fit nicely.
Here is a slightly modified example, to illustrate the difference between
required permissions. I'm mentioning PK columns in the required permissions,
just as other columns.
{code}
// Table schema definition:
CREATE ks.t1 (p int, c int, v int, w int, PRIMARY KEY (p,c));
// Accessing individual columns:
INSERT INTO ks.t1(p, c, v) VALUES (0, 0, 0); // requires MODIFY on at least
ks.t1(p, c, v)
SELECT v FROM ks.t1 WHERE p = 0 AND c = 0; // requires SELECT on at least
ks.t1(p, v)
UPDATE ks.t1 SET v = 1 WHERE p = 0 AND v = 0; // requires MODIFY on at least
ks.t1(p, v)
DELETE v FROM ks.t1 WHERE p = 0 AND v = 0; // requires MODIFY on at least
ks.t1(p, v)
// Accessing whole rows (all columns):
SELECT * FROM ks.t1 WHERE p = 0 AND c = 0; // requires SELECT on at least
ks.t1(p, c, v, w)
DELETE FROM ks.t1 WHERE p = 0 AND c = 0; // requires MODIFY on at least
ks.t1(p, c, v, w)
DELETE FROM ks.t1 WHERE p = 0; // requires MODIFY on at least
ks.t1(p, c, v, w)
TRUNCATE ks.t1; // requires MODIFY on at least
ks.t1(p, c, v, w)
{code}
> Column-level permissions
>
>
> Key: CASSANDRA-12859
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12859
> Project: Cassandra
> Issue Type: New Feature
> Components: Core, CQL
>Reporter: Boris Melamed
> Attachments: Cassandra Proposal - Column-level permissions.docx
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> h4. Here is a draft of:
> Cassandra Proposal - Column-level permissions.docx (attached)
> h4. Quoting the 'Overview' section:
> The purpose of this proposal is to add column-level (field-level) permissions
> to Cassandra. It is my intent to soon start implementing this feature in a
> fork, and to submit a pull request once it’s ready.
> h4. Motivation
> Cassandra already supports permissions on keyspace and table (column family)
> level. Sources:
> * http://www.datastax.com/dev/blog/role-based-access-control-in-cassandra
> * https://cassandra.apache.org/doc/latest/cql/security.html#data-control
> At IBM, we have use cases in the area of big data analytics where
> column-level access permissions are also a requirement. All industry RDBMS
> products are supporting this level of permission control, and regulators are
> expecting it from all data-based systems.
> h4. Main day-one requirements
> # Extend CQL (Cassandra Query Language) to be able to optionally specify a
> list of individual columns, in the {{GRANT}} statement. The relevant
> permission types are: {{MODIFY}} (for {{UPDATE}} and {{INSERT}}) and
> {{SELECT}}.
> # Persist the optional information in the appropriate system table
> ‘system_auth.role_permissions’.
> # Enforce the column access restrictions during execution. Details:
> #* Should fit with the existing permission propagation down a role chain.
> #* Proposed message format when a user’s roles give access to the queried
> table but not to all of the selected, inserted, or updated columns:
> "User %s has no %s permission on column %s of table %s"
> #* Error will report only the first checked column.
> Nice to have: list all inaccessible columns.
> #* Error code is the same as for table access denial: 2100.
> h4. Additional day-one requirements
> # Reflect the column-level permissions in statements of type
> {{LIST ALL PERMISSIONS OF someuser;}}
> # Performance should not degrade in any significant way.
> # Backwards compatibility
> #* Permission enforcement
[jira] [Comment Edited] (CASSANDRA-12859) Column-level permissions
[
https://issues.apache.org/jira/browse/CASSANDRA-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15625503#comment-15625503
]
Boris Melamed edited comment on CASSANDRA-12859 at 11/1/16 2:17 PM:
Thank you, that would indeed fit nicely.
Here is a slightly modified example, to illustrate the difference between
required permissions. I'm mentioning PK columns in the required permissions,
just as other columns.
{code}
// Table schema definition:
CREATE ks.t1 (p int, c int, v int, w int, PRIMARY KEY (p,c));
// Accessing individual columns:
INSERT INTO ks.t1(p, c, v) VALUES (0, 0, 0); // requires MODIFY on at least
ks.t1(p, c, v)
SELECT v FROM ks.t1 WHERE p = 0 AND c = 0; // requires SELECT on at least
ks.t1(p, v)
UPDATE ks.t1 SET v = 1 WHERE p = 0 AND v = 0; // requires MODIFY on at least
ks.t1(p, v)
DELETE v FROM ks.t1 WHERE p = 0 AND v = 0; // requires MODIFY on at least
ks.t1(p, v)
// Accessing whole rows (all columns):
SELECT * FROM ks.t1 WHERE p = 0 AND c = 0; // requires SELECT on at least
ks.t1(p, c, v, w)
DELETE FROM ks.t1 WHERE p = 0 AND c = 0; // requires MODIFY on at least
ks.t1(p, c, v, w)
DELETE FROM ks.t1 WHERE p = 0; // requires MODIFY on at least
ks.t1(p, c, v, w)
TRUNCATE ks.t1; // requires MODIFY on at least
ks.t1(p, c, v, w)
{code}
was (Author: bmel):
Thank you, that would indeed fit nicely.
Here is a slightly modified example, to illustrate the difference between
required permissions. Note that in RDBMSs, even PK columns need to be given
access explicitly even for upsert. Following this approach could help avoid
confusion.
{code}
// Table schema definition:
CREATE ks.t1 (p int, c int, v int, w int, PRIMARY KEY (p,c));
// Accessing individual columns:
INSERT INTO ks.t1(p, c, v) VALUES (0, 0, 0); // requires MODIFY on at least
ks.t1(p, c, v)
SELECT v FROM ks.t1 WHERE p = 0 AND c = 0; // requires SELECT on at least
ks.t1(p, v)
UPDATE ks.t1 SET v = 1 WHERE p = 0 AND v = 0; // requires MODIFY on at least
ks.t1(p, v)
DELETE v FROM ks.t1 WHERE p = 0 AND v = 0; // requires MODIFY on at least
ks.t1(p, v)
// Accessing whole rows (all columns):
SELECT * FROM ks.t1 WHERE p = 0 AND c = 0; // requires SELECT on at least
ks.t1(p, c, v, w)
DELETE FROM ks.t1 WHERE p = 0 AND c = 0; // requires MODIFY on at least
ks.t1(p, c, v, w)
DELETE FROM ks.t1 WHERE p = 0; // requires MODIFY on at least
ks.t1(p, c, v, w)
TRUNCATE ks.t1; // requires MODIFY on at least
ks.t1(p, c, v, w)
{code}
> Column-level permissions
>
>
> Key: CASSANDRA-12859
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12859
> Project: Cassandra
> Issue Type: New Feature
> Components: Core, CQL
>Reporter: Boris Melamed
> Attachments: Cassandra Proposal - Column-level permissions.docx
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> h4. Here is a draft of:
> Cassandra Proposal - Column-level permissions.docx (attached)
> h4. Quoting the 'Overview' section:
> The purpose of this proposal is to add column-level (field-level) permissions
> to Cassandra. It is my intent to soon start implementing this feature in a
> fork, and to submit a pull request once it’s ready.
> h4. Motivation
> Cassandra already supports permissions on keyspace and table (column family)
> level. Sources:
> * http://www.datastax.com/dev/blog/role-based-access-control-in-cassandra
> * https://cassandra.apache.org/doc/latest/cql/security.html#data-control
> At IBM, we have use cases in the area of big data analytics where
> column-level access permissions are also a requirement. All industry RDBMS
> products are supporting this level of permission control, and regulators are
> expecting it from all data-based systems.
> h4. Main day-one requirements
> # Extend CQL (Cassandra Query Language) to be able to optionally specify a
> list of individual columns, in the {{GRANT}} statement. The relevant
> permission types are: {{MODIFY}} (for {{UPDATE}} and {{INSERT}}) and
> {{SELECT}}.
> # Persist the optional information in the appropriate system table
> ‘system_auth.role_permissions’.
> # Enforce the column access restrictions during execution. Details:
> #* Should fit with the existing permission propagation down a role chain.
> #* Proposed message format when a user’s roles give access to the queried
> table but not to all of the selected, inserted, or updated columns:
> "User %s has no %s permission on column %s of table %s"
> #* Error will report only the first checked column.
> Nice to have: list all inaccessible columns.
> #* Error code is the same as for table access denial: 2100.
> h4. Additional day-one requirements
> # Reflect the column-level permissions in statements of type
>
[jira] [Comment Edited] (CASSANDRA-12859) Column-level permissions
[
https://issues.apache.org/jira/browse/CASSANDRA-12859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15622591#comment-15622591
]
Boris Melamed edited comment on CASSANDRA-12859 at 10/31/16 4:13 PM:
-
Thank you for giving this doc your attention, and for your feedback.
I was taking cues from what the big RDBMS products have to offer, mainly DB2
and Oracle.
Now to your points:
h4. MODIFY as also including DELETE and TRUNCATE.
I remember seeing a previous request to divide it up. The reason given not to
divide was that once you have UPDATE rights, you can also effectively remove
whole rows (DELETE, TRUNCATE). However, with column permissions, this is no
longer the case. I agree that it's scary (or outright wrong) to allow someone
with a mere column permission to remove whole rows. On the other hand, if
DELETE requires a MODIFY permission without any column restrictions, then there
is no way (even if needed) of allowing anyone to delete rows unless they have
UPDATE permissions for the whole table. Possibly, that's a valid stipulation -
TBD.
{quote}
Why not just process deletes/truncates the same as inserts?
{quote}
For inserts, I intended to reject statements that set columns for which the
user has no access permissions. Are you saying that INSERTs should not be
restricted by columns?
(Note that primary key columns must be allowed, or else no INSERT/UPDATE is
possible. I shall add this to the doc...)
Should we add a new permission type, such as UPDATE or UPSERT, after all?
h4. GRANT - additive or replacing?
In Oracle and DB2, it's actually required to REVOKE table permissions,
before changing the list of included columns in any way.
I've intended allowing 'replacing' GRANTs as syntactic sugar.
But now, it seems to me that the "spartan" way is the most unambiguous one.
If one wants to add or remove one or more columns from the list of included
columns, then e.g.:
{code}
GRANT SELECT (col_a, col_b) ON ks.t1 TO foo; // role foo has access to col_a
and col_b
REVOKE SELECT ON ks.t1 FROM foo; // removing the previous access to table t1,
thus clearing column perms there as well
GRANT SELECT (col_a, col_b, col_c) ON ks.t1 TO foo; // now, foo has permissions
on all of col_a, col_b, col_c
{code}
Having said this, there are several DB products that do allow revoking of
permissions on certain columns. There, it would make sense to have the additive
column GRANTing paradigm, as your intuition suggests.
However, possible problems with that approach, as user-friendly as it appears,
are:
# More complexity: grammar addition for REVOKE statements as well.
# Possible confusion: users may erroneously think that the following allows
access to all columns (including future ones) except col_a:
{code}
GRANT SELECT ON ks.t1 TO foo;
REVOKE SELECT (col_a) ON ks.t1 FROM foo;
{code}
Of course, this will not work unless we implement black lists, which we have
not thought of doing.
As a remedy, we could return an error when REVOKE refers to a column that does
not exist.
If there are strong feelings for having this more elaborate paradigm, then we
can do that.
Otherwise, at least in the first step, I'd go for the 'spartan' approach where
any column list change requires a previous REVOKE on the whole table, for that
role, table, and permission type. The nice thing being that there will be no
issue with backwards compatibility going forward, since we are not deciding
whether GRANTed columns are additive or replacing; it's simply forbidden to
GRANT again, without first REVOKEing.
h4. Misc
* Thank you for unit test pointers.
* Absolutely, dropped columns must trigger cleanup of permissions, thanks for
pointing this out.
* Grammar- indeed. It would be simpler to have the non-standard syntax:
{code}
GRANT SELECT ON ks.t1 (col_a, ...) TO foo;
{code}
If there are no objections, I may go for that. Or else, the code could check
and throw an exception if the resource is not a table.
* I shall look deeper into the code and come back about the IResource aspect.
was (Author: bmel):
Thank you for giving this doc your attention, and for your feedback.
I was taking cues from what the big RDBMS products have to offer, mainly DB2
and Oracle.
Now to your points:
h4. MODIFY as also including DELETE and TRUNCATE.
I remember seeing a previous request to divide it up. The reason given not to
divide was that once you have UPDATE rights, you can also effectively remove
whole rows (DELETE, TRUNCATE). However, with column permissions, this is no
longer the case. I understand that it's scary (or outright wrong) to allow
someone with a mere column permission to remove whole rows. On the other hands,
if DELETE requires MODIFY permission without column restrictions, then there is
no way (even if needed) of allowing anyone to delete rows unless they have
UPDATE every column. Possibly, that's a valid
