oracle.8.0.5.intelligent.agent.txt

`Date: Fri, 30 Apr 1999 14:11:39 +0100  
From: Anthony Clarke <[email protected]>  
To: [email protected]  
Subject: *Huge* security hole in Oracle 8.0.5 with Intellegent agent installed oracle-digested  
  
------------- Begin Forwarded Message -------------  
  
Subject: *Huge* security hole in Oracle 8.0.5 with Intellegent agent installed  
>From: Dan Sugalski <[email protected]>  
Date: Thu, 29 Apr 1999 08:34:30 -0700  
X-Message-Number: 46  
Subject: oracle-digested  
  
Folks,  
  
This is a big heads up for everyone. If you're running Oracle 8.0.5 on a  
Unix box, do *not* install and configure the Intellegent Agent option. If  
you have, find the bin/oratclsh file and REMOVE THE SUID BIT!  
  
oratclsh is a Tcl app that provides full access to Tcl. It's also installed  
as suid root. Running oratclsh gives anyone with even the most modest Tcl  
knowledge the ability to execute arbitrary Tcl commands *while running as  
root*! This includes the exec command, which spawns off a subshell (as  
root) to run any command on the system. Anyone with half a brain is exactly  
three commands away from full root access. Anyone with a whole brain is  
exactly *one* command away from full root access.  
  
This hole has been verified on both Linux and Solaris with Oracle 8.0.5. It  
probably exists in all Unix versions of 8.0.5. Whether it exists in later  
versions is unknown. (I don't believe it exists in 8.0.4, but I can't  
verify that at the moment) I also don't know if it affects non-Unix  
versions of 8.0.5.  
  
Once again, Intellegent Agent only needs to be *installed* (and the root.sh  
part of the setup run) to open this hole. The agent does *not* need to be  
started--just installed.  
  
Dan  
  
---------------------------------------------"it's like this"--------------  
Dan Sugalski (541) 737-3346 even samurai  
SysAdmin have teddy bears  
Oregon University System and even the teddy bears  
[email protected] get drunk  
  
----------------------------------------------------------------------  
  
------------- End Forwarded Message -------------  
  
  
============ ==================================  
Ian Harrison Phone: +44 (0)181 214 2121  
Oracle DBA Fax: +44 (0)181 214 4473  
One2One Email: [email protected]  
============ ==================================  
  
  
------------- End Forwarded Message -------------  
  
-----------------------------------------------------------------------------------  
  
Date: Sat, 1 May 1999 11:18:34 +0200  
From: Markus Friedl <[email protected]>  
To: [email protected]  
Subject: Re: *Huge* security hole in Oracle 8.0.5 with Intellegent agent installedoracle-digested  
  
On Fri, Apr 30, 1999 at 02:11:39PM +0100, Anthony Clarke wrote:  
> This hole has been verified on both Linux and Solaris with Oracle 8.0.5. It  
> probably exists in all Unix versions of 8.0.5. Whether it exists in later  
> versions is unknown. (I don't believe it exists in 8.0.4, but I can't  
> verify that at the moment)  
  
verified: the sbit-hole _does_ exists version 8.0.4/solaris, too:  
ORATCLSH for Solaris: Version 8.0.4.0.0 - Production on 01-MAY-99 11:14:41  
  
-markus  
  
-----------------------------------------------------------------------------------  
  
Date: Fri, 30 Apr 1999 16:49:03 -0700  
From: John Ritchie <[email protected]>  
To: [email protected]  
Subject: Re: *Huge* security hole in Oracle 8.0.5 with Intellegent agent  
  
On Fri, 30 Apr 1999, Anthony Clarke wrote:  
  
> ------------- Begin Forwarded Message -------------  
>  
> Subject: *Huge* security hole in Oracle 8.0.5 with Intellegent agent installed  
> From: Dan Sugalski <[email protected]>  
> Date: Thu, 29 Apr 1999 08:34:30 -0700  
> X-Message-Number: 46  
> Subject: oracle-digested  
>  
> Folks,  
>  
> This is a big heads up for everyone. If you're running Oracle 8.0.5 on a  
> Unix box, do *not* install and configure the Intellegent Agent option. If  
> you have, find the bin/oratclsh file and REMOVE THE SUID BIT!  
>  
> oratclsh is a Tcl app that provides full access to Tcl. It's also installed  
> as suid root. Running oratclsh gives anyone with even the most modest Tcl  
> knowledge the ability to execute arbitrary Tcl commands *while running as  
> root*! This includes the exec command, which spawns off a subshell (as  
> root) to run any command on the system. Anyone with half a brain is exactly  
> three commands away from full root access. Anyone with a whole brain is  
> exactly *one* command away from full root access.  
>  
> This hole has been verified on both Linux and Solaris with Oracle 8.0.5. It  
> probably exists in all Unix versions of 8.0.5. Whether it exists in later  
> versions is unknown. (I don't believe it exists in 8.0.4, but I can't  
> verify that at the moment) I also don't know if it affects non-Unix  
> versions of 8.0.5.  
>  
> Once again, Intellegent Agent only needs to be *installed* (and the root.sh  
> part of the setup run) to open this hole. The agent does *not* need to be  
> started--just installed.  
>  
> Dan  
>  
  
Here's the followup for this (rather, the original story):  
  
I opened a TAR with Oracle on this and, after typical Oracle shuffling  
("It's not a bug it's a feature", "We don't know how that got there",  
"You'll have to file an Enhancement Request", etc) they finally got  
back to me today to say that this will be fixed in future releases (8.0.6,  
etc.). On current releases one should just chown the  
$ORACLE_HOME/bin/oratclsh to oracle (or whoever the install userid is); on  
Linux and Solaris that will also remove the suid bit.  
  
When I pressed them as to whether or not they would release patches and  
information to users who already have 8.0.5 installed they said they had  
no mechanism to do that. In other words, YOYO. (They could learn  
something about patch releases and access from their good buddies at Sun).  
  
So if you've installed Oracle's Intelligent Agent or aren't sure if it's  
installed then check your oratclsh and fix that bit. The only systems  
I've had experience on are 8.0.5 for Solaris and Linux but I'd check any  
8.x release on any platform if it were mine.  
  
John Ritchie  
Systems Software Analyst  
Oregon University System  
  
-----------------------------------------------------------------------------------  
  
Date: Mon, 3 May 1999 14:31:46 +0000  
From: David Adrian <[email protected]>  
To: [email protected]  
Subject: Re: *Huge* security hole in Oracle 8.0.5 with Intellegent agent  
  
John Ritchie wrote:  
  
> On Fri, 30 Apr 1999, Anthony Clarke wrote:  
>  
>  
> When I pressed them as to whether or not they would release patches and  
> information to users who already have 8.0.5 installed they said they had  
> no mechanism to do that. In other words, YOYO. (They could learn  
> something about patch releases and access from their good buddies at Sun).  
>  
> So if you've installed Oracle's Intelligent Agent or aren't sure if it's  
> installed then check your oratclsh and fix that bit. The only systems  
> I've had experience on are 8.0.5 for Solaris and Linux but I'd check any  
> 8.x release on any platform if it were mine.  
>  
> John Ritchie  
> Systems Software Analyst  
> Oregon University System  
  
I patched my Linux version of oracle to 8.0.5.1. When I checked for this  
vulnerability, the suid bit was not set, and the ownership of oratclsh was  
oracle.oracle.  
So it seems likely that upgrading to 8.0.5.1 will fix the problem. On Linux,  
this was necessary to fix many other nasty bugs anyway.  
  
David Adrian  
[email protected]  
  
-----------------------------------------------------------------------------------  
  
Date: Mon, 3 May 1999 08:34:45 -0500  
From: Dave Diehl <[email protected]>  
To: [email protected]  
Subject: Re: *Huge* security hole in Oracle 8.0.5 with Intellegent agent installedoracle-digested  
  
> On Fri, Apr 30, 1999 at 02:11:39PM +0100, Anthony Clarke wrote:  
>> This hole has been verified on both Linux and Solaris with Oracle 8.0.5.  
>> It probably exists in all Unix versions of 8.0.5. Whether it exists in  
>> later versions is unknown. (I don't believe it exists in 8.0.4, but I  
>> can't verify that at the moment)  
>  
  
verified: this hole exists under Oracle 8.0.5 on Digital Unix.  
  
-Dave Diehl  
Systems/Network Manager  
Carleton College  
  
-----------------------------------------------------------------------------------  
  
Date: Mon, 3 May 1999 18:31:36 -0500  
From: Jeff Long <[email protected]>  
To: [email protected]  
Subject: Re: *Huge* security hole in Oracle 8.0.5 with Intellegent agent  
  
David Adrian wrote:  
>  
> John Ritchie wrote:  
>  
> > On Fri, 30 Apr 1999, Anthony Clarke wrote:  
<snip>  
  
> > So if you've installed Oracle's Intelligent Agent or aren't sure if it's  
> > installed then check your oratclsh and fix that bit. The only systems  
> > I've had experience on are 8.0.5 for Solaris and Linux but I'd check any  
> > 8.x release on any platform if it were mine.  
<snip>  
  
> I patched my Linux version of oracle to 8.0.5.1. When I checked for this  
> vulnerability, the suid bit was not set, and the ownership of oratclsh was  
> oracle.oracle.  
> So it seems likely that upgrading to 8.0.5.1 will fix the problem. On Linux,  
> this was necessary to fix many other nasty bugs anyway.  
  
Well, I patched to 8.0.5.1 on Digital Unix a while ago and discovered on  
Friday that oratclsh was still suid root so at least on my platform  
8.0.5.1 did not solve the problem.  
  
Jeff Long  
  
-----------------------------------------------------------------------------------  
  
Date: Tue, 4 May 1999 09:41:24 -0400  
From: Paul Diehl <[email protected]>  
To: [email protected]  
Subject: Re: *Huge* security hole in Oracle 8.0.5 with Intellegent agent installedoracle-digested  
  
On Fri, Apr 30, 1999 at 02:11:39PM +0100, Anthony Clarke wrote:  
> This hole has been verified on both Linux and Solaris with Oracle 8.0.5. It  
> probably exists in all Unix versions of 8.0.5. Whether it exists in later  
> versions is unknown. (I don't believe it exists in 8.0.4, but I can't  
> verify that at the moment)  
  
This hole exists for Oracle 8.0.3 on Solaris as well.  
  
Paul Diehl  
Oracle Database Administrator  
Sumaria Systems, Inc. Contractor  
F-16 System Program Office (ASC/YPOM)  
DSN 785-8719, COMM (937) 255-8719  
[email protected]  
  
-----------------------------------------------------------------------------------  
  
Date: Tue, 4 May 1999 02:56:04 +0200  
From: Kis-Szabo Andras <[email protected]>  
To: [email protected]  
Subject: Re: Oracle Intellegent agent installedoracle-digested  
  
On Mon, 3 May 1999, Dave Diehl wrote:  
  
=- > On Fri, Apr 30, 1999 at 02:11:39PM +0100, Anthony Clarke wrote:  
=- >> This hole has been verified on both Linux and Solaris with Oracle 8.0.5.  
=- >> It probably exists in all Unix versions of 8.0.5. Whether it exists in  
=- >> later versions is unknown. (I don't believe it exists in 8.0.4, but I  
=- >> can't verify that at the moment)  
  
  
Oracle8i 8.1.5 Solaris 7  
-rwsr-s--x 1 root dba 1402152 May 3 01:08 /oracle/bin/oratclsh  
  
After the install. This version never run here before.  
  
  
--  
Kis-Szabo Andras Technical University of Budapest  
-----------------------------/ Schonherz Zoltan Dormitory  
[email protected] /-------------------------------3OO---->>.Info  
Fingerprint = 97 D7 32 CE F9 74 5C A0 E5 F4 09 29 67 9F A8 78  
  
-----------------------------------------------------------------------------------  
  
Date: Wed, 5 May 1999 00:22:34 -0400  
From: Chris Hallenbeck <[email protected]>  
To: [email protected]  
Subject: Re: Oracle Intellegent agent installedoracle-digested  
  
On Tue, 4 May 1999, Kis-Szabo Andras wrote:  
  
> Oracle8i 8.1.5 Solaris 7  
> -rwsr-s--x 1 root dba 1402152 May 3 01:08  
/oracle/bin/oratclsh  
>  
> After the install. This version never run here before.  
  
Solaris 2.6 with Oracle8.0.5 ...installed by the userid "oracle", hence  
we have:  
-rwsr-s--x 1 oracle dba 1492432 Jan 7 08:19 oratclsh  
  
Solution? Try running the majority of the install as the "oracle" user.  
  
Comments?  
  
HTH!  
  
-Chris Hallenbeck  
--  
----------------------------------------------------------  
Chris Hallenbeck UNIX Systems Administrator  
Computing Services [email protected]  
Binghamton University Phone: 607-777-6188  
Binghamton, NY 13902-6000 Fax: 607-777-4009  
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%  
  
-----------------------------------------------------------------------------------  
  
Date: Wed, 5 May 1999 16:52:44 +0800  
From: Yung-Sheng Tang <[email protected]>  
To: [email protected]  
Subject: Re: *Huge* security hole in Oracle 8.0.5 with Intellegent agent installedoracle-digested  
  
On Tue, 4 May 1999, Paul Diehl wrote:  
  
> On Fri, Apr 30, 1999 at 02:11:39PM +0100, Anthony Clarke wrote:  
> > This hole has been verified on both Linux and Solaris with Oracle 8.0.5. It  
> > probably exists in all Unix versions of 8.0.5. Whether it exists in later  
> > versions is unknown. (I don't believe it exists in 8.0.4, but I can't  
> > verify that at the moment)  
>  
> This hole exists for Oracle 8.0.3 on Solaris as well.  
>  
  
Maybe not. Our Oracle 8.0.3 on Solaris doesn't have root-owned oratclsh.  
  
-----------------------------------------------------------------------------------  
  
Date: Wed, 5 May 1999 14:04:38 +0200  
From: "[email protected]" <[email protected]>  
To: [email protected]  
Subject: Re: *Huge* security hole in Oracle 8.0.5 with Intellegent agent installedoracle-digested  
  
-----Original Message-----  
From: Anthony Clarke [SMTP:[email protected]]  
Sent: Friday, April 30, 1999 3:12 PM  
To: [email protected]  
Subject: *Huge* security hole in Oracle 8.0.5 with  
Intellegent agent installedoracle-digested  
  
This hole has been verified on both Linux and Solaris with Oracle 8.0.5. It  
probably exists in all Unix versions of 8.0.5. Whether it exists in later  
versions is unknown. (I don't believe it exists in 8.0.4, but I can't  
verify that at the moment) I also don't know if it affects non-Unix versions of 8.0.5.  
-----Original Message-----  
  
And is now verified on AIX.  
  
Oracle 8i 8.0.5 on AIX 4.3.1.0 running on a RS/6000 F50:  
  
-rwsr-xr-x 1 root dba 6849934 Jul 13 1998 oratclsh  
  
My best regards,  
Peter Fredriksson  
Systems administrator  
Skriptor AB  
email - [email protected]  
  
-----------------------------------------------------------------------------------  
  
Date: Thu, 6 May 1999 13:36:33 -0700  
From: John Ritchie <[email protected]>  
To: [email protected]  
Subject: Re: Oracle Intellegent agent installedoracle-digested  
  
On Wed, 5 May 1999, Chris Hallenbeck wrote:  
  
> On Tue, 4 May 1999, Kis-Szabo Andras wrote:  
>  
> > Oracle8i 8.1.5 Solaris 7  
> > -rwsr-s--x 1 root dba 1402152 May 3 01:08  
> /oracle/bin/oratclsh  
> >  
> > After the install. This version never run here before.  
>  
> Solaris 2.6 with Oracle8.0.5 ...installed by the userid "oracle", hence  
> we have:  
> -rwsr-s--x 1 oracle dba 1492432 Jan 7 08:19 oratclsh  
>  
> Solution? Try running the majority of the install as the "oracle" user.  
>  
> Comments?  
>  
> HTH!  
>  
> -Chris Hallenbeck  
  
The root setuid gets set when you run the post-install root.sh as root  
(per the install instructions). If you don't run root.sh as root  
(directly after the Intelligent Agent install - remember Oracle creates a  
new root.sh with every install) then the file will be owned by the  
installer ID (typically oracle).  
  
I would suggest that setuid oracle on that file is bad enough. The simple  
exploit will then get you oracle:dba privs instead of root, but that would  
be enough to have full control of the database. Oracle's recommended fix  
of removing the setuid bit would still apply.  
  
John Ritchie  
Oregon University System  
  
-----------------------------------------------------------------------------------  
  
Date: Thu, 6 May 1999 16:01:17 -0700  
From: John Ritchie <[email protected]>  
To: [email protected]  
Subject: Oracle Security Followup, patch and FAQ: setuid on oratclsh  
Parts/Attachments:  
1 Shown ~92 lines Text (charset: ISO-8859-1)  
2 Shown 225 lines Text, "setuid_patch.sh"  
----------------------------------------  
  
All,  
The following message and patch was sent to us from Oracle regarding the oratclsh setuid vulnerability. If you're an  
Oracle Metalink member you can get this patch off their website; if not then here it is.  
Note that this removes oratclsh completely, and removes setuid bits from a whole bunch of other executables. I see this is  
a good sign: maybe Oracle is starting to get as nervous about weak setuid protections as we all are. :^)   
I've removed all the HTML formatting from the following FAQ.  
John Ritchie Systems Software Analyst Oregon University System  
---------- Forwarded message ---------- [Oracle contact names removed to protect the innocent]  
This e-mail is in response to your concern expressed in your e-mail entitled: "*Huge* security hole in Oracle 8.0.5 with  
Intellegent agent".   
  
The Oracle Security Development team, along with the Oracle Worldwide Support group have looked into this issue. We've  
done research and found the setuid issue extended a bit beyond the oratclsh file.   
  
So, attached is a patch in the form of a shell script which we are issuing today to our customers via our Worldwide  
Customer Support web page (MetaLink). Also below this message is the FAQ about this patch, which is also being posted to  
MetaLink.   
[more Oracle Support name info deleted]  
-----   
  
Q: I've heard about a setuid security issue with the Oracle database? What is this all about?   
A: On Unix platforms, some executable files have the setuid bit on. It may be possible for a very knowledgeable user to  
use these executables to bypass your system security by elevating their operating system privileges to that of the Oracle  
user.   
Q: I've also heard about a security issue with the Intelligent Agent? What is this all about?  
A: It^Òs basically the same problem as above, but specifically applies to a utility executable called oratclsh which is  
included in your Intelligent Agent installation. It is a separate program that is not used by the Intelligent Agent.  
Q: Which releases are affected by this problem?  
A: This problem affects Oracle data server releases 8.03, 8.0.4, 8.0.5, and 8.1.5 on UNIX^Ù platforms only.  
Q: Can I correct this problem or do I need a patch?  
A: This problem can easily be corrected. The customer can download the patch from the Oracle MetaLink webpages at  
<http://www.oracle.com/support/elec_sup>http://www.oracle.com/support/elec_sup. The patch is a UNIX^Ù shell script. This  
shell script should be run immediately, and also run after each relink of Oracle.  
Q: Is the Oracle Intelligent Agent secure?  
A: Yes, the Oracle Intelligent Agent is secure. All tasks performed by the Intelligent Agent require username/password  
authentication. The Intelligent Agent can only perform a task for which appropriate credentials -- for the operating  
system and/or database -- have been provided.  
Q: What is Oracle doing to fix this problem?  
A: Effective immediately, Oracle will provide the patch on Oracle^Òs Worldwide Support Web pages. Oracle will ensure the  
patches are incorporated into future releases of Oracle8i (8.1.6) and Oracle8.0 (8.0.6)   
Q: What is Oracle doing to notify users about this problem now?  
A: Oracle is notifying all supported customers, via the Oracle Worldwide Support Web pages, of this issue so they can  
address it as required.  
  
[ Part 2: "setuid_patch.sh" ]  
  
#!/bin/sh  
#  
# NAME  
# setuid_patch.sh  
#  
# DESCRIPTION  
# Provided as a patch to 8.0.X and 8.1.5 to fix bugs 701297, 714293.  
# These bugs introduce a security hole by changing the permissions  
# to affect the effective user id for executables which should not  
# be set this way.  
#  
# PRECONDITIONS  
# if ORACLE_HOME is not set, doesn't exist, or points to an  
# invalid location, script exits.  
#  
# HOW TO USE  
# This script must be run as the oracle user who installed the 8.0.3  
# 8.0.4, 8.0.5 or 8.1.5 software.  
#  
# To run, change directories into the the directory that contains this  
# file.  
# % cd <patch_location_directory>  
#  
# Add execute permission to the patch.  
# % chmod 744 setuid_patch.sh  
#  
# Then, invoke the script.  
# % ./setuid_patch.sh  
#  
# MODIFIED (MM/DD/YY)  
# menash 5/3/99 Initial creation  
  
##---------------------  
## VARIABLE DEFINITIONS  
  
#-----------------------------  
# potentially platform specific variables  
  
CHMOD="/bin/chmod"  
FIND="/bin/find"  
CHMOD_S="$CHMOD -s" # remove set id bit  
RM_F="/bin/rm -f"  
LS_L="/bin/ls -l"  
LS_N="/bin/ls -n" # gives uid number for owner  
SED="/bin/sed"  
AWK="/bin/awk"  
GREP="/bin/grep"  
GREP_C="$GREP -c"  
GREP_V="$GREP -v"  
MV="/bin/mv"  
TMP_DIR="/tmp"  
  
EXECS_TO_UNSET="lsnrctl oemevent onrsd osslogin tnslsnr tnsping trcasst trcroute cmctl cmadmin cmgw names namesctl otrccref  
otrcfmt otrcrep otrccol oracleO"  
EXECS_NOT_TO_UNSET="oracle dbsnmp"  
EXECS_TO_REMOVE="oratclsh osh"  
LIKELY_SUFFIXES="0 O"  
ROOT_SH_815="$ORACLE_HOME/root.sh"  
ROOT_SH_805="$ORACLE_HOME/orainst/root.sh"  
  
  
if [ x${ORACLE_HOME} = x ] -o [ ${ORACLE_HOME} = "" ] ; then  
echo "ORACLE_HOME is either unset or empty."  
echo "Exiting ..."  
exit 1  
fi  
  
#--------------  
# usage message  
  
SCRIPTNAME=setuid_patch.sh  
USAGE="Usage: $SCRIPTNAME [-h]"  
if [ $# -gt 1 ] ; then  
echo  
echo $USAGE  
exit 2  
fi  
  
  
##-----------#  
## FUNCTIONS #  
##-----------#  
  
# ----------  
# setuid_off  
  
# Assumes executable is in $ORACLE_HOME/bin  
#  
# Usage: setuid_off <executable>  
#------------  
  
setuid_off () {  
  
exe=$1  
full_path_exe=$ORACLE_HOME/bin/$exe  
if [ -r $full_path_exe ] ; then  
perm=`$LS_L $full_path_exe | $SED 's;r-.*;;'`  
if [ $perm = "-rws" ] ; then  
$CHMOD_S $full_path_exe  
echo " removing set-ID from $full_path_exe"  
fi  
fi  
}  
  
#-----------  
# remove_exe  
# Assumes executable is in $ORACLE_HOME/bin  
# Removes if owned by root, otherwise, calls setuid_off  
  
# Usage: remove_exe <executable>  
remove_exe () {  
  
full_path_exe=$ORACLE_HOME/bin/$1  
if [ -r $full_path_exe ] ; then  
owner=`$LS_N $full_path_exe | $AWK '{print $3}'`  
if [ $owner = "0" ] ; then  
$RM_F $full_path_exe  
echo " removing $full_path_exe..."  
else  
setuid_off $1  
fi  
fi  
}  
  
#-----------  
# search_for_others  
#  
# Finds other executables n $ORACLE_HOME/bin which have 4000, 6000,  
# or 2000 permissions except for those we expects, and warns the  
# user that they should be removed manually  
  
# Usage: search_for_others  
  
search_for_others () {  
  
all_others="`$FIND $ORACLE_HOME/bin -perm -2000`"  
others=""   
if [ x"${all_others}" != x ] ; then  
for other in $all_others; do  
match="false"  
for exe in $EXECS_NOT_TO_UNSET; do  
if [ $other = $ORACLE_HOME/bin/$exe ] ; then  
match="true"   
fi   
done  
if [ $match = "false" ] ; then  
others="$others $other"  
fi   
done   
if [ x"${others}" != x ] ; then  
echo "The following executables remain with set-ID."  
echo "You may need to change the permissions manually:"  
for executable in $others; do  
echo " $executable"  
done   
fi  
fi  
  
}  
  
#--------  
# remove_from_root_sh  
  
# For each parameter it is passed, remove_from_root_sh removes all  
# lines with references to that string.  
  
# Usage: remove_from_root_sh [ string1, string2, etc. ]  
  
remove_from_root_sh () {  
  
strings=$*  
tmp_file="root.sh.$$"   
$RM_F $TMP_DIR/$tmp_file  
for string in $strings; do  
if [ `$GREP_C $string $ROOT_SH` != "0" ] ; then  
echo " removing $string from $ROOT_SH"  
fi  
$GREP_V $string $ROOT_SH > $TMP_DIR/$tmp_file  
$MV $TMP_DIR/$tmp_file $ROOT_SH  
done  
  
}  
  
################  
# MAIN EXECUTION  
################  
  
# Turn setuid bit off for the appropriate executables and their  
# likely backups  
  
for exe in $EXECS_TO_UNSET; do  
setuid_off $exe  
for suf in $LIKELY_SUFFIXES; do  
setuid_off $exe$suf  
done  
done  
  
# Remove files entirely which should be removed  
  
for exe in $EXECS_TO_REMOVE; do  
remove_exe $exe  
done  
  
# Determine version -- 8.0.5 or 8.1.5  
# Backup existing root.sh into root.sh.old, removing references  
# to EXECS_TO_REMOVE  
if [ -r $ROOT_SH_805 ] ; then  
ROOT_SH=$ROOT_SH_805  
else  
if [ -r $ROOT_SH_815 ] ; then  
ROOT_SH=$ROOT_SH_815  
else  
echo "No root.sh found in $ORACLE_HOME"  
fi  
fi  
  
if [ x${ROOT_SH} != x ] ; then  
remove_from_root_sh $EXECS_TO_REMOVE  
fi  
  
# Check one last time to see if any setuid executables are left  
  
search_for_others  
  
`