Root.sh - documentation

Question

Hi. We have a customer who is very concerned about security. They own the root user and will be running root.sh. They are asking questions like 'why does oracle need to change permissions on some files to root'? Does anyone know of any documentation that describes they "why" of root.sh ?
Specifically these commands are in question:
$CHMOD 4710 $ORACLE_HOME/bin/nmo
$CHMOD 4710 $ORACLE_HOME/bin/nmb
$CHMOD 4710 $ORACLE_HOME/bin/nmhs
$CHMOD 4750 $ORACLE_HOME/bin/oradism
$CHMOD 4750 $ORACLE_HOME/bin/extjob
$CHMOD 4750 $ORACLE_HOME/bin/jssu
$CHMOD 4555 $FILEMAPLOC/bin/fmputlhp
$CHOWN root $ORACLE_HOME/bin/nmo
$CHOWN root $ORACLE_HOME/bin/nmb
$CHOWN root $ORACLE_HOME/bin/nmhs
$CHOWN root $ORACLE_HOME/bin/oradism
$CHOWN root $ORACLE_HOME/bin/extjob
$CHOWN root $ORACLE_HOME/rdbms/admin/externaljob.ora
$CHOWN root $ORACLE_HOME/bin/jssu
Thanks, -Dan

Answer 1

The idea of root.sh is to separate out the administrative tasks that require root. I think this used to be explained somewhere in the docs, but I don't see it now. Perhaps it is self-explanatory, as those utilities need setuid access, dealing with shared memory and disk and such. Perhaps you need to open a service request to get a more detailed explanation of what those utilities are. The oracle executable itself needs to be able to spawn processes for the logged in user with oracle's privileges. So for example, you can see I've gone into sqlplus as jeg, I own the process that can access the oracle-owned files, which only oracle can write to:
$ ps -ef|grep 26184
  oracle 26197 20532  0 17:11:29 pts/0     0:00 grep 26184
jeg 26187 26184  0 17:11:11 ?         0:00 oracleTTST (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
jeg 26184 20559  0 17:11:07 pts/2     0:00 sqlplus
$ ll `which oracle`
-rwsr-s--x   1 oracle     oinstall   284467056 May 29  2008 /oracle/app/oracle/product/10.2.0/db_1/bin/oracleIt is correct for them to be worried about security with setuid, but then again, all this has been pounded on for years by experts and hackers, so if you follow the directions, including patching, most worry should come from inside jobs. And if you don't trust your own insiders, auditing, and division of responsibility, you have more of a problem than Oracle.