| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: java package to run OS command
By default, no user accounts in the Oracle DB have any privs to do anything
to the OS. Privs -- including privs to execute, read, and write OS files --
must explicitly be granted (and rightly so!).
Do not grant the JAVASYSPRIV or JAVAUSERPRIV to the schema that will own the ExecOS Java code, as these roles have full access to all files on the OS. This will be overridden by OS security, but since the Java will execute as the oracle instance owner, this leaves the oracle software, instance configurations, and datafiles open to damage or erasure.
SELECT *
FROM DBA_JAVA_POLICY;
As an interesting aside, on Unix servers it appears that one only needs the
"execute" java.io.FilePermission to execute a command, where on the
filesystem security you need read/execute. Ahhhh, memories of RMS and
proper security.
Rich
Rich Jesse System/Database Administrator rjesse_at_qtiworld.com Quad/Tech Inc, Sussex, WI USA
-----Original Message-----
Sent: Thursday, December 04, 2003 12:29 PM
To: Multiple recipients of list ORACLE-L
Dick, harsh words, hmmm? Powerful tools can also be powerful weapons in the wrong hands. But don't blame the toolmaker.
John, the reason that running an OS command is such a hassle is that it can be horribly destructive to your server. An OS command that runs from a Java Stored Procedure such as the one from www.oracle-base.com that I gave you or the one that Tom Kyte wrote and published on Ask Tom will have all the permissions of the oracle database. Which means that it can be abused to absolutely destroy the database, just as in Dick's example.
Doing this with an external procedure as we do is also dangerous. If you use a separate Oracle Net listener for them, instead of LISTENER, and have another user besides the database owner (usually oracle) start that listener, and password protect the listener, you can at least have some control over the permissions, which will be those of the user that starts the listener. People who run Oracle under Windows may be out of luck here - it is harder to get this running under a less privileged account in Windows.
We do one more thing for security. We have a special schema in the database called COMMON that owns tables and stored procedures that are usable by all applications. We put the stub program for the external procedure that executes OS commands in a package as a private procedure. The public procedure that calls this private procedure can examine the OS command first. Certain commands, like "rm -fr" are absolutely forbidden, and raise an exception. Other commands are checked against the PRODUCT_PROFILE table which we set up much as for restrictions for what commands certain users may run in SQL*Plus. If the current user (or schema) does not have the explicit privilege to run that OS command, we raise an exception.
You could easily put a similar protective shell around the Java version of
the same thing.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Jesse, Rich
INET: Rich.Jesse_at_qtiworld.com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services ---------------------------------------------------------------------To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). Received on Thu Dec 04 2003 - 12:54:26 CST
 |
 |