hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "huaxiang sun (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-14554) Investigate the server side alternative to enable dynamic jar for security purpose
Date Tue, 06 Oct 2015 00:40:26 GMT

     [ https://issues.apache.org/jira/browse/HBASE-14554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

huaxiang sun updated HBASE-14554:
---------------------------------
    Description: 
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."

  was:
>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."


> 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: huaxiang sun
>            Assignee: huaxiang sun
>             Fix For: 2.0.0
>
>
> 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
(v6.3.4#6332)

Mime
View raw message