File ownership after patching or relinking Oracle RDBMS software

Some time ago I received the warning message “chmod: changing permissions of ‘/u00/app/oracle/product/11.2.0.4/bin/extjobO’: Operation not permitted” when patching the Oracle RDBMS at a customer site. This was the reason for me, to check what happens to file permissions and ownership when patching or relinking Oracle RDBMS software.

Deutsche Übersetzung dieses Posts auf www.markusdba.de

As we all know, the permissions of some Oracle executables have to be changed on Linux/Unix after the installation. This is done by “root.sh”.

After a fresh installation and running root.sh (Oracle 18c – 18.3 on Linux) $ORACLE_HOME/bin looks like:

oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l |grep root
-rwxr-xr-x. 1 oracle oinstall       945 Jun 20  2016 acfsroot
-rwxr-xr-x. 1 oracle oinstall      1000 Jun 20  2016 afdroot
-rwsr-x---. 1 root   oinstall   2580328 Oct  2 09:17 extjob
-rwsr-x---. 1 root   oinstall   2366584 Oct  2 09:17 jssu
-rwxr-xr-x. 1 oracle oinstall       940 Jun 20  2016 okaroot
-rwxr-xr-x. 1 oracle oinstall      1007 Jun 20  2016 olfsroot
-rwsr-x---. 1 root   oinstall     98210 Feb  7  2018 oradism
-rwx------. 1 oracle oinstall      2139 Sep 19  2017 rootPreRequired.sh

==> The ownership of extjob, jssu and oradism was changed to “root” by root.sh

Let’s apply a patch …

After applying patch 28655784 (Database RU 18.4) the permissions have changed:

oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l |grep root
-rwxr-xr-x. 1 oracle oinstall       945 Jun 20  2016 acfsroot
-rwxr-xr-x. 1 oracle oinstall      1000 Jun 20  2016 afdroot
-rwsr-x---. 1 root   oinstall   2366584 Oct  2 09:17 jssu
-rwxr-xr-x. 1 oracle oinstall       940 Jun 20  2016 okaroot
-rwxr-xr-x. 1 oracle oinstall      1007 Jun 20  2016 olfsroot
-rwsr-x---. 1 root   oinstall     98210 Feb  7  2018 oradism
-rwx------. 1 oracle oinstall      2139 Sep 19  2017 rootPreRequired.sh
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l extjob
-rwxr-xr-x. 1 oracle oinstall 2580328 Nov 18 11:48 extjob

==> jssu and oradism were not changed, but “extjob” is now owned by oracle.

As external jobs are rarely used (my personal impression) most users won’t be affected by this issue. But to be on the safe side, it’s a good idea to correct the ownership by running root.sh again (this is a not-documented post-patch-installation step 🙂 ):

oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] cd ..
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/ [rdbms18000] su
Password:
root@oramaster18:/u00/app/oracle/product/18.0.0.0/ [rdbms18000] ./root.sh
Check /u00/app/oracle/product/18.0.0.0/install/root_oramaster18.markusdba.local_2018-11-18_11-51-41-270759279.log for the output of root script
root@oramaster18:/u00/app/oracle/product/18.0.0.0/ [rdbms18000] exit
exit
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/ [rdbms18000] cd bin
/u00/app/oracle/product/18.0.0.0/bin
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l |grep root
-rwxr-xr-x. 1 oracle oinstall       945 Jun 20  2016 acfsroot
-rwxr-xr-x. 1 oracle oinstall      1000 Jun 20  2016 afdroot
-rwsr-x---. 1 root   oinstall   2580328 Nov 18 11:48 extjob
-rwsr-x---. 1 root   oinstall   2366584 Oct  2 09:17 jssu
-rwxr-xr-x. 1 oracle oinstall       940 Jun 20  2016 okaroot
-rwxr-xr-x. 1 oracle oinstall      1007 Jun 20  2016 olfsroot
-rwsr-x---. 1 root   oinstall     98210 Feb  7  2018 oradism
-rwx------. 1 oracle oinstall      2139 Sep 19  2017 rootPreRequired.sh

Of course, this step is necessary only if one of the files is affected by the patch.

What happens during a relink?

oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] relink all
writing relink log to: /u00/app/oracle/homes/OraDB18Home1/install/relink_2018-11-18_11-52-23AM.log
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l |grep root
-rwxr-xr-x. 1 oracle oinstall 945 Jun 20 2016 acfsroot
-rwxr-xr-x. 1 oracle oinstall 1000 Jun 20 2016 afdroot
-rwxr-xr-x. 1 oracle oinstall 940 Jun 20 2016 okaroot
-rwxr-xr-x. 1 oracle oinstall 1007 Jun 20 2016 olfsroot
-rwsr-x---. 1 root oinstall 98210 Feb 7 2018 oradism
-rwx------. 1 oracle oinstall 2139 Sep 19 2017 rootPreRequired.sh
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l extjob
-rwxr-xr-x. 1 oracle oinstall 2580328 Nov 18 11:52 extjob

So it’s a good idea to run root.sh again (this is documented in MOS-Note “Executing “relink all” resets permission of extjob, jssu, oradism, externaljob.ora (Doc ID 1555453.1)”, too.

oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] su
Password:
root@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] cd ..
root@oramaster18:/u00/app/oracle/product/18.0.0.0/ [rdbms18000] ./root.sh
Check /u00/app/oracle/product/18.0.0.0/install/root_oramaster18.markusdba.local_2018-11-18_11-56-04-603314902.log for the output of root script
root@oramaster18:/u00/app/oracle/product/18.0.0.0/ [rdbms18000] exit
exit
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l extjob
-rwsr-x---. 1 root oinstall 2580328 Nov 18 11:52 extjob

Conclusion:
Although it is not documented, I think it’s a good idea to run root.sh after patching (or at least to check the ownership of the files in question). When relinking the RDBMS software (which is a recommended step e.g. after kernel updates) running “root.sh” afterwards is a must (IMHO).

MOS-Notes

  • What Are Root.sh And OrainstRoot.sh Scripts In A Standalone RDBMS Installation? (Doc ID 1493121.1)
  • Why are files under $ORACLE_HOME owned by root user? (Doc ID 461144.1)
  • Executing “relink all” resets permission of extjob, jssu, oradism, externaljob.ora (Doc ID 1555453.1)
  • Relinking Oracle Home FAQ ( Frequently Asked Questions) (Doc ID 1467060.1)

Ad (Amazon Link):
This entry was posted in Common. Bookmark the permalink.