[
https://issues.apache.org/jira/browse/TRAFODION-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987528#comment-14987528
]
Hans Zeller commented on TRAFODION-1578:
----------------------------------------
We should make sure that the solution to this problem satisfies the following
requirements:
1. Security: UDR libraries should not be easy targets for a "spoofing" attack,
where an unauthorized person can substitute their own code for a previously
created library. Right now this is an issue, because libraries can have
arbitrary file names and be owned by any user. I think we need to "sandbox" all
the UDR libraries into a directory that is secured for access by the trafodion
user, something like $MY_SQROOT/export/lib/udr. We should refuse to load UDR
library files that are not owned by the trafodion user or are not in the
sandboxed directory - at least in configurations where security is enabled.
2. Replication to all nodes in the cluster: Libraries need to be available on
all nodes of the Trafodion cluster, even if nodes are down while a library is
being created or if new nodes are added after creating the library. Updates to
libraries also need to be propagated. Storing the library in HDFS or in a LOB
can solve that. We need to have a local cache, since DLLs and jar files can't
be loaded directly from HDFS or from a LOB.
3. Backup and Restore: Backing up and restoring a database should also back up
and restore the libraries. Using LOBs to store them solves this problem
(assuming we include LOBs in our backups).
> Proposal for SPJ management
> ---------------------------
>
> Key: TRAFODION-1578
> URL: https://issues.apache.org/jira/browse/TRAFODION-1578
> Project: Apache Trafodion
> Issue Type: Improvement
> Components: connectivity-dcs
> Reporter: Kevin Xu
>
> JAR upload process:
> 1. Initialize JAR upload procedure by default
> 2. JAR upload by Trafci(add library LIB_NAME JAR_LOCAL_PATH). Upload and
> create library will be done here. And also, you can only upload the JARs by
> UPLOAD command on Trafci that it will not create a lib.
> Tips: Before put the JAR into HDFS check MD5 first, if the file exists,
> only add a record in metadata table in case users upload the same JAR many
> times on platform.
> 3. On server-side, the JAR will store in HDFS. At the same time JAR
> metadata(path in HDFS, MD5 of the file, and others) stores in store procedure
> metadata table.
> 4. create procedure is the same as now.
> JAR perform process:
> 1. Send a CALL by Trafci/JDBC/ODBC/ADO.NET.
> 2. DCSMaster assign a DCSServer for the CALL.
> 3. DCSServer start a JVM for the user. User can modify JVM options, program
> properties and JAVA classpath. At the same time, a monitor class will be
> starting in the JVM witch will register a node on Zookeeper for this JVM as
> well as metadata info( process id, server info and so on) and the node will
> be removed while JVM exiting. It allows customer to specify JVM idle time in
> case of some realtime senarior like Kafka consumer.
> 4. Useful commands on Trafci: list all JVMs in user; kill one of them that no
> long in use; Restart JVMs with latest JARs and so on.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
