Thanks for all the replies...I'm wading through them! One more question...Do I always need to specify the full path of a Unix command e.g /usr/bin/mv rather then just mv
That is something I don't currently need to do when using an external procedure. John -----Original Message----- Sent: 04 December 2003 20:15 To: Multiple recipients of list ORACLE-L No, but it disallows command chains - only single commands are permitted. If you want to run more than one command you have to write it as a shell script, and the full path to that shell script must be approved for the current user in the PRODUCT_PROFILE table. Normally, we will only allow scripts to run from certain controlled directories. But we need to be able to permit commands that we didn't think about when we wrote the procedure, and prefer to do this table driven rather than by changing programs. -----Original Message----- Sent: Thursday, December 04, 2003 1:39 PM To: Multiple recipients of list ORACLE-L will it catch following command apart from "rm -rf" ??? find /var/opt/oracle/logs -mtime +1 -type f -name "*.trc"|perl -nle unlink Probably not ... and that's why it is dangerous ... basically you should have a set of fixed programs that can be called and accept only arguments from calling programs. That will give at-least more control. Raj ---------------------------------------------------------------------------- ---- Rajendra dot Jamadagni at nospamespn dot com All Views expressed in this email are strictly personal. QOTD: Any clod can have facts, having an opinion is an art ! -----Original Message----- Sent: Thursday, December 04, 2003 1: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. **************************************************************************** ********** This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you. **************************************************************************** **********4 -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jamadagni, Rajendra INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: John Flack INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: John Dunn INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
