[
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)
