[
https://issues.apache.org/jira/browse/HBASE-14554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Kyle Purtell resolved HBASE-14554.
-----------------------------------------
Assignee: (was: Hua Xiang)
Resolution: Incomplete
> Investigate the server side alternative to enable dynamic jar for security
> purpose
> ----------------------------------------------------------------------------------
>
> Key: HBASE-14554
> URL: https://issues.apache.org/jira/browse/HBASE-14554
> Project: HBase
> Issue Type: Bug
> Reporter: Hua Xiang
> Priority: Major
>
> Per HBASE-14347, from [~mbertozzi] "for 2.x we probably want to do some
> changes. the DynamicLoader seems to not be needed on the client side, so we
> should force that to "not enabled". but on the server side we probably want
> that still on, to allow user filters and so on. do we have any alternative to
> copy local instead of forcing that "not enable" with security reason as
> motivation? how one is supposed to use custom filters in a "secure"
> environment otherwise?"
> "Esteban Gutierrez in theory we are already supposed to do the "remote" load.
> the problem is the code that copies those "remote" locally. I think that was
> done because it was the easy way to load the class form remote since you have
> the friendly API that loads the class by using addUrl() where url is expected
> to be something that java understand and hdfs is not.
> Looking at the classLoader API there is a defineClass() that takes an array
> of bytes. In theory we can leverage that to open the hdfs stream (the jar we
> want to load) and add the class to our class loader and avoid the
> copy-to-local step. In that way we can get even rid of the tmp dir.
> https://docs.oracle.com/javase/7/docs/api/java/security/SecureClassLoader.html#defineClass(java.lang.String,%20byte[],%20int,%20int,%20java.security.CodeSource)
> I'll let huaxiang sun look into that, if it is something possible or not."
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
