[
https://issues.apache.org/jira/browse/HBASE-16700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clay B. updated HBASE-16700:
----------------------------
Attachment: HBASE-16700.002.patch
[~enis] Thank you!
* Forgetting {{preCreateTable()}} would have been a bad omission; that's been
fixed and test cases added
* I had not read the configuration string that way; it is now changed.
* Here I want to allow for whitelisting coprocessors, but as once can always be
sneaky (or ignorant) and use someone else's class name in a multi-tenant
environment, the only permissioning point I could get a handle on was the
filesystem. Shy of having class signing, it seems the class name would be too
weak of a control? This does leave off any relationship between which table can
use which coprocessor (probably a more reasonable control in a non-cooperative
multi-tenant environment.)
* I would expect the admin should know what was on their cluster before this
coprocessor was deployed. I can not think of a way to shim in a new table
descriptor without going through the master API's or having access to HDFS as
the hbase user?
* As to loading from a {{file:///}} scheme only, I have whacked the path
handling logic, so one can now use wildcards (sadly only that supported by
[FilenameUtils.wildcardMatch|https://commons.apache.org/proper/commons-io/javadocs/api-1.4/org/apache/commons/io/FilenameUtils.html#wildcardMatch(java.lang.String,%20java.lang.String)]
and not the more flexible Ant directory globbing style) and the scheme of the
filesystem is now checked; further one can use {{*}} to allow all. This ensures
one can now use {{file:///}} for whitelisting but no {{hdfs:///}} paths to
achieve what you have asked for Phoenix (or any local coprocessors). Keep in
mind {{file:///usr/lib/phoenix/*}} would likely be safer as can not a user
specify a coprocessor, if available on every RS, via
{{file:///home/clay/my_coprocessor.jar}}?
> Allow for coprocessor whitelisting
> ----------------------------------
>
> Key: HBASE-16700
> URL: https://issues.apache.org/jira/browse/HBASE-16700
> Project: HBase
> Issue Type: Improvement
> Components: Coprocessors
> Reporter: Clay B.
> Priority: Minor
> Labels: security
> Attachments: HBASE-16700.000.patch, HBASE-16700.001.patch,
> HBASE-16700.002.patch
>
>
> Today one can turn off all non-system coprocessors with
> {{hbase.coprocessor.user.enabled}} however, this disables very useful things
> like Apache Phoenix's coprocessors. Some tenants of a multi-user HBase may
> also need to run bespoke coprocessors. But as an operator I would not want
> wanton coprocessor usage. Ideally, one could do one of two things:
> * Allow coprocessors defined in {{hbase-site.xml}} -- this can only be
> administratively changed in most cases
> * Allow coprocessors from table descriptors but only if the coprocessor is
> whitelisted
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
