[jira] [Comment Edited] (CASSANDRA-10552) Pluggable IResources

["Anthony Cozzie (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-10552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14965366#comment-14965366 ] 

Anthony Cozzie edited comment on CASSANDRA-10552 at 10/20/15 4:43 PM:
----------------------------------------------------------------------

It seems I have fallen into my classic trap of 'this shouldn't be too bad' . . . . 'I've made a huge mistake'.  Fixing both of these problems is somewhat difficult.  The different types of roles are somewhat entangled with the CQL grammar, and it doesn't seem possible to specify keywords that aren't hard coded.  Loading classes at runtime would require adding another dependency to the project (probably Reflections, but maybe Objectweb) which seems dubious.  [~beobal] and I discussed three possible solutions this morning, but none look all that great.

1, We can have extensions have the full class path as their string representation.  So rather than data/keyspace/table or roles/blah it would be com.foo.bar.ResourceClass/type/subtype.  At that point, the {{Resource}} class can simply load the classes it finds in {{system_auth.role_permissions}}.  Unfortunately, this leads to a truly miserable CQL syntax: {{GRANT MODIFY ON CUSTOM RESOURCE com.foo.bar.ResourceClass/type/subtype}}.

2, We can register new auth types in some sort of system table.  Unfortunately, I don't think this improves the CQL syntax much: {{GRANT MODIFY ON CUSTOM RESOURCE ALIAS blah.blah}} and it adds a lot of complexity.

3, We can add a Cassandra {{IResource}} extension, say {{UserResource}}.  The CQL syntax is about the same as #2 {{GRANT MODIFY ON URESOURCE alias/blah/blah}} but it's much simpler internally.  However, {{UserResource}} would not be able to properly implement {{IResource.exists()}} or {{IResource.applicablePermissions()}}, which is also pretty ugly.

We also questioned the long term validity of some of this stuff.  If vtables become the preferred form of access, then the normal access controls are just fine.


was (Author: acoz):
It seems I have fallen into my classic trap of 'this shouldn't be too bad' . . . . 'I've made a huge mistake'.  Fixing both of these problems is somewhat difficult.  The different types of roles are somewhat entangled with the CQL grammar, and it doesn't seem possible to specify keywords that aren't hard coded.  Loading classes at runtime would require adding another dependency to the project (probably Reflections, but maybe Objectweb) which seems dubious.  [~beobal] and I discussed three possible solutions this morning, but both have rather serious flaws.

1, We can have extensions have the full class path as their string representation.  So rather than data/keyspace/table or roles/blah it would be com.foo.bar.ResourceClass/type/subtype.  At that point, the {{Resource}} class can simply load the classes it finds in {{system_auth.role_permissions}}.  Unfortunately, this leads to a truly miserable CQL syntax: {{GRANT MODIFY ON CUSTOM RESOURCE com.foo.bar.ResourceClass/type/subtype}}.

2, We can register new auth types in some sort of system table.  Unfortunately, I don't think this improves the CQL syntax much: {{GRANT MODIFY ON CUSTOM RESOURCE ALIAS blah.blah}} and it adds a lot of complexity.

3, We can add a Cassandra {{IResource}} extension, say {{UserResource}}.  The CQL syntax is about the same as #2 {{GRANT MODIFY ON URESOURCE alias/blah/blah}} but it's much simpler internally.  However, {{UserResource}} would not be able to properly implement {{IResource.exists()}} or {{IResource.applicablePermissions()}}, which is also pretty ugly.

> Pluggable IResources
> --------------------
>
>                 Key: CASSANDRA-10552
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10552
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Anthony Cozzie
>            Assignee: Anthony Cozzie
>             Fix For: 3.x
>
>         Attachments: cassandra-3.0.0-10552.txt
>
>
> It is impossible to add new IResources because of the static method Resources.fromName(), which creates IResources from the text values in the authentication tables.  This patch replaces the static list of checks with a hash table that can be extended.



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