Hi Kevin, it would be up to you to describe what permissions you would use
in SecurityManager to make sure that
- the UDR *can not* ...
- ...connect to HBase or HDFS, since it is running under the
"trafodion" id and could read any Trafodion table in HBase as well as any
Hive tables any Trafodion user has access to.
- ...do local file operations as the trafodion id
- ...connect to other processes or nodes in the cluster and
masquerade as a Trafodion process
- the UDR *can* ...
- ... perform Trafodion SQL operations, preferrably using the T2
driver, otherwise we lose the advantage of running in the same JVM
- ... use other Java code like JDBC drivers, Spark, Kafka, MongoDB,
etc.
Would you agree that we are talking about three flavors of UDR? The current
proposal has trusted and isolated. You are proposing a new flavor, maybe we
can call it "sandboxed". It might be interesting to know whether Oracle
uses that approach. I know IBM DB2 better and think it uses only the
"trusted" and "isolated" approach, in DB2 that's called "NOT FENCED" and
"FENCED". Fenced DB2 UDRs run in a separate process with a different id.
If SecurityManager can not make UDRs both secure and reasonably powerful,
then we will probably need the other two flavors, and I don't think
implementing three flavors is a good idea. I would argue that it only makes
sense to replace one of the other two with the new approach.
Thanks,
Hans
On Sun, Nov 8, 2015 at 11:34 PM, Xu, Kai-Hua (Kevin) <[email protected]>
wrote:
> Hi,
> I have replied on the JIRA with more details. New SPJ path will be
> DCSMaster->DCSServer->create a new JVM( starting up with jdbcT2) comparing
> with DCSMaster->DCSServer->SQ engine ->UDR ->jdbcT2.
>
> About Java SecurityManager, it has many Permissions and Security Policy,
> such as FilePermissions, SocketPermission and so on. More details ref to
> http://docs.oracle.com/javase/6/docs/technotes/guides/security/spec/security-spec.doc3.html
>
> Best Regards,
> Kevin Xu
>
>
> -----邮件原件-----
> 发件人: Hans Zeller [mailto:[email protected]]
> 发送时间: 2015年11月8日 17:07
> 收件人: Liu, Ming (Ming) <[email protected]>
> 抄送: [email protected]; Venkat Muthuswamy <
> [email protected]>
> 主题: Re: TRAFODION-1578 Proposal for SPJ management
>
> Hi,
>
> Thanks, Ming. I wanted to add a bit more info about some of these concerns
> and commented on the JIRA with some more details:
> https://issues.apache.org/jira/browse/TRAFODION-1578.
>
> About Java SecurityManager: I don't know this component very well, but it
> seems like a library for checking which operations are valid. Does it help
> with the issues mentioned in the comments to the JIRA? Could you explain
> where we would use Java SecurityManager and what it would do?
>
> Thanks,
>
> Hans
>
> On Sat, Nov 7, 2015 at 8:01 PM, Liu, Ming (Ming) <[email protected]>
> wrote:
>
> > Hi, Kevin,
> >
> > We need to understand how security concern is address in more detail.
> > Suresh/Venkat, could you provide more details about what particular
> > security issue you are still not clear?
> > Given Kevin's proposal of using Java SecurityManager, do you still
> > think there are security issue we need to address?
> >
> > And the second question to be answer by you Kevin:
> > What is the JVM management mean? People still not quite understand it.
> > Could you explain it a little more?
> > I think the basic idea is to avoid UDR and launch a JVM from T2 or
> > Mxosrvr directly upon a request of 'CALL'. But please Kevin give more
> details.
> >
> > Thanks,
> > Ming
> >
> > -----邮件原件-----
> > 发件人: Xu, Kai-Hua (Kevin) [mailto:[email protected]]
> > 发送时间: 2015年11月6日 8:46
> > 收件人: [email protected]
> > 抄送: Hans Zeller <[email protected]>; Venkat Muthuswamy <
> > [email protected]>
> > 主题: 答复: TRAFODION-1578 Proposal for SPJ management
> >
> > Add Hans and Venkat. I’m not sure whether you have seen it or not.
> >
> > Best Regards,
> > Kevin Xu
> >
> > 发件人: Xu, Kai-Hua (Kevin)
> > 发送时间: 2015年11月4日 18:44
> > 收件人: '[email protected]' <
> > [email protected]>
> > 主题: TRAFODION-1578 Proposal for SPJ management
> >
> > Hi all,
> >
> > As recommended, it should be better for Apache Trafodion. Hans/Venkat,
> > thanks for your comments.
> >
> >
> > 1. Security: it may use Java SecurityManager and POLICY. It allows
> > to set a particular directory access permission for a JVM.
> >
> > 2. 1) If the JARs don’t exist at the first time, the JARs will be
> > copied to local, as well as when it has new updates. Check JARs every
> > time once starting JVM.
> >
> > 2) Only update the JARs for the node needed. If node is down, JARs
> > will be copied from HDFS again if needed(check MD5 if the file exists)
> > 3. Let’s create a procedure or sth for downloading and packing.
> > Should be easy to pack the JARs.
> > 4. As I said, there is an idle time for the JVM and DCSMaster will
> > assign the same existing JVM for a CALL. Assume there is a JAR with
> > size 10Mb, that it can be split into 10 parts(1Mb/part). Add a head
> > for every part(1/10, 2/10 …). Validate MD5 while all parts are done.
> > 5. JVM is isolated with its own process id. The PID is stored into
> > Zookeeper, so list all JVM is trying to list all the JVMs that the
> > current user owned. It might be implemented on DCS-side that it’ll be
> > available for all client drivers.
> > 6. Yes, check the size and the head of package as well as total size.
> > It’s opensourced that some bad guys also can do that.
> >
> >
> > Best Regards,
> > Kevin Xu
> >
> >
> >
>
