[jira] [Commented] (CASSANDRA-4295) move checkaccess into statement.prepare
[ https://issues.apache.org/jira/browse/CASSANDRA-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13489629#comment-13489629 ] Aleksey Yeschenko commented on CASSANDRA-4295: -- bq. Could we add an invalidation hook to the API so that when permissions are changed, it can notify us and we can go through the cache and throw out obsolete entries? What if we enable caching for IAuthority2 only? And then invalidate the cache after calling IAuthority2.grant() and revoke() in GrantStatement/RevokeStatement? move checkaccess into statement.prepare --- Key: CASSANDRA-4295 URL: https://issues.apache.org/jira/browse/CASSANDRA-4295 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.1.0 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.2.0 Attachments: CASSANDRA-4295.patch there's no need to redo this every execution since the schema, tables, and users involved should all be immutable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4295) move checkaccess into statement.prepare
[ https://issues.apache.org/jira/browse/CASSANDRA-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13489677#comment-13489677 ] Jonathan Ellis commented on CASSANDRA-4295: --- Sounds reasonable. move checkaccess into statement.prepare --- Key: CASSANDRA-4295 URL: https://issues.apache.org/jira/browse/CASSANDRA-4295 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.1.0 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.2.0 Attachments: CASSANDRA-4295.patch there's no need to redo this every execution since the schema, tables, and users involved should all be immutable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4295) move checkaccess into statement.prepare
[ https://issues.apache.org/jira/browse/CASSANDRA-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13489698#comment-13489698 ] Aleksey Yeschenko commented on CASSANDRA-4295: -- Reasonable, but probably not easily implementable, now that I think of it. Will only work for a single-node 'cluster' since GRANT/REVOKE are executed on the coordinator node only. The coordinator will have to somehow signal the event to other nodes and that's gossip abuse. An invalidation hook won't work for the same reason. move checkaccess into statement.prepare --- Key: CASSANDRA-4295 URL: https://issues.apache.org/jira/browse/CASSANDRA-4295 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.1.0 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.2.0 Attachments: CASSANDRA-4295.patch there's no need to redo this every execution since the schema, tables, and users involved should all be immutable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4295) move checkaccess into statement.prepare
[ https://issues.apache.org/jira/browse/CASSANDRA-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13489712#comment-13489712 ] Aleksey Yeschenko commented on CASSANDRA-4295: -- But time-based caching would be helpful, as long as the period is configurable or reasonably low (I'm thinking a couple seconds/tenths of a second maybe). move checkaccess into statement.prepare --- Key: CASSANDRA-4295 URL: https://issues.apache.org/jira/browse/CASSANDRA-4295 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.1.0 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.2.0 Attachments: CASSANDRA-4295.patch there's no need to redo this every execution since the schema, tables, and users involved should all be immutable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4295) move checkaccess into statement.prepare
[ https://issues.apache.org/jira/browse/CASSANDRA-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13420874#comment-13420874 ] Jonathan Ellis commented on CASSANDRA-4295: --- Not a fan of splitting the API up. Feels like we're shoving implementation up to the client level. Not a fan of saying each provider should reimplement caching internally, either, since by doing it once at the server level we can do a better job of QA and DRY. move checkaccess into statement.prepare --- Key: CASSANDRA-4295 URL: https://issues.apache.org/jira/browse/CASSANDRA-4295 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.1.0 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.2 Attachments: CASSANDRA-4295.patch there's no need to redo this every execution since the schema, tables, and users involved should all be immutable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4295) move checkaccess into statement.prepare
[ https://issues.apache.org/jira/browse/CASSANDRA-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13420897#comment-13420897 ] Sylvain Lebresne commented on CASSANDRA-4295: - Maybe doing the caching on our side with a configurable cache expiration time setting would be good enough. move checkaccess into statement.prepare --- Key: CASSANDRA-4295 URL: https://issues.apache.org/jira/browse/CASSANDRA-4295 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.1.0 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.2 Attachments: CASSANDRA-4295.patch there's no need to redo this every execution since the schema, tables, and users involved should all be immutable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4295) move checkaccess into statement.prepare
[ https://issues.apache.org/jira/browse/CASSANDRA-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13420911#comment-13420911 ] Jonathan Ellis commented on CASSANDRA-4295: --- That's probably reasonable to start with. Could we add an invalidation hook to the API so that when permissions are changed, it can notify us and we can go through the cache and throw out obsolete entries? move checkaccess into statement.prepare --- Key: CASSANDRA-4295 URL: https://issues.apache.org/jira/browse/CASSANDRA-4295 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.1.0 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.2 Attachments: CASSANDRA-4295.patch there's no need to redo this every execution since the schema, tables, and users involved should all be immutable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4295) move checkaccess into statement.prepare
[
https://issues.apache.org/jira/browse/CASSANDRA-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13413649#comment-13413649
]
Sylvain Lebresne commented on CASSANDRA-4295:
-
The current {{IAuthority}} API is:
{noformat}
public EnumSetPermission authorize(AuthenticatedUser user, ListObject
resource);
{noformat}
What about changing that to something like:
{noformat}
public interface PermissionToken {}
public PairEnumSetPermission, PermissionToken authorize(AuthenticatedUser
user, ListObject resource);
public boolean isStillValid(PermissionToken token);
{noformat}
The semantic being that authorize would give us a token (every implementation
could make that be whatever they want) and {{isStillValid}} would validate
whether the authorization that returned the token is still valid at the time of
the call to {{isStillValid}}.
Implementations that don't want to get fancy could just return null as the
token and have {{isStillValid}} return either:
- always true if an authorization is valid indefinitely
- always false to force redoing an authorization every time
And more fancier policy (like authorization is valid for X minutes only, ...)
can be easily implemented too.
Then in CQL we would call authorize during preparation and keep the token
around, and during execution we would check the validity of the token and redo
the authorization only if it's not valid anymore. It does complicate think a
bit, but not too much either.
Or we just leave things like they are and consider that caching the result of
authorize should be the business of the {{IAuthority}} (I'm personally not
against that). But the more I think about it, the more I'm convince that
forcing users and their access rights to be immutable is A Bad Idea.
move checkaccess into statement.prepare
---
Key: CASSANDRA-4295
URL: https://issues.apache.org/jira/browse/CASSANDRA-4295
Project: Cassandra
Issue Type: Improvement
Components: API
Affects Versions: 1.1.0
Reporter: Jonathan Ellis
Assignee: Pavel Yaskevich
Priority: Minor
Fix For: 1.1.3
Attachments: CASSANDRA-4295.patch
there's no need to redo this every execution since the schema, tables, and
users involved should all be immutable
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4295) move checkaccess into statement.prepare
[ https://issues.apache.org/jira/browse/CASSANDRA-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13401510#comment-13401510 ] Sylvain Lebresne commented on CASSANDRA-4295: - So I will admit I'm a little uncomfortable committing something without having a solution for the case where access right change over time (which the patch don't tackle unless I'm misreading it). Access rights are a security feature, so it feel to me we don't want to start to get too sloppy. I'm almost inclined to say that the caching of access rights (which is basically what we're talking about) is something the auth API should be in charge of doing (since it can do it better). Or we make it part of the spec that access for prepared statement are checked during preparation only, which is an option, but that sounds a bit weak to me. At least we shouldn't make that decision lightly. move checkaccess into statement.prepare --- Key: CASSANDRA-4295 URL: https://issues.apache.org/jira/browse/CASSANDRA-4295 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.1.0 Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 1.1.2 Attachments: CASSANDRA-4295.patch there's no need to redo this every execution since the schema, tables, and users involved should all be immutable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4295) move checkaccess into statement.prepare
[ https://issues.apache.org/jira/browse/CASSANDRA-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285700#comment-13285700 ] Sylvain Lebresne commented on CASSANDRA-4295: - Couldn't we imagine that the access themselves may change? I could imagine wanting to upgrade/downgrade access authorizations over time. move checkaccess into statement.prepare --- Key: CASSANDRA-4295 URL: https://issues.apache.org/jira/browse/CASSANDRA-4295 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.1.0 Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.1.2 there's no need to redo this every execution since the schema, tables, and users involved should all be immutable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4295) move checkaccess into statement.prepare
[ https://issues.apache.org/jira/browse/CASSANDRA-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285778#comment-13285778 ] Jonathan Ellis commented on CASSANDRA-4295: --- I suppose, but they'd be *relatively* static, so adding a validated boolean that we can negate when permissions change should be adequate. Most (all?) production implementations of the auth API are going to call into a remote service to validate credentials, so that feels like something worth optimizing away if we can. move checkaccess into statement.prepare --- Key: CASSANDRA-4295 URL: https://issues.apache.org/jira/browse/CASSANDRA-4295 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.1.0 Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.1.2 there's no need to redo this every execution since the schema, tables, and users involved should all be immutable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4295) move checkaccess into statement.prepare
[ https://issues.apache.org/jira/browse/CASSANDRA-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285933#comment-13285933 ] Sylvain Lebresne commented on CASSANDRA-4295: - bq. Most (all?) production implementations of the auth API are going to call into a remote service to validate credentials, so that feels like something worth optimizing away if we can. Make sense. Though the validated business does suppose that we're able to say when permission changes (I'm not sure all production implementation of the auth API will provide that). Anyway, I'll give that a shot and we can readapt a bit if that's not good enough for some auth implementation. move checkaccess into statement.prepare --- Key: CASSANDRA-4295 URL: https://issues.apache.org/jira/browse/CASSANDRA-4295 Project: Cassandra Issue Type: Improvement Components: API Affects Versions: 1.1.0 Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.1.2 there's no need to redo this every execution since the schema, tables, and users involved should all be immutable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
