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).

Reply via email to