Aus aktuellem Anlass hier eine kleine Anekdote:
wenn ich als ein OS-User, der nicht oracle und auch nicht in der oinstall-Gruppe (oder einer sonstigen Besitzer-Gruppe des ORACLE_HOME) ist, versuche, SQL*Plus auszuführen, bekomme ich nach Einspielung eines Patches (in diesem Fall das aktuelle PSU) folgenden Fehler:
sqlplus: error while loading shared libraries: libsqlplus.so: cannot open shared object file: No such file or directory
Das Problem ist, dass in $ORACLE_HOME/lib die Library libsqlplus.so falsche Berechtigungen hat, nämlich diese:
-rw-r----- 1 oracle oinstall 1548657 Jul 19 11:36 libsqlplus.so
Richtig wäre aber :
-rw-r--r-- 1 oracle oinstall 1548657 Jul 19 11:36 libsqlplus.so
, also Leserecht für alle.
Dies entspricht nach MOS (Achtung: Oracle-Support-Vertrag / CSI erforderlich!) dem
Bug 22730454 – „libsqlplus.so: Permission denied“ after patch application (Doc ID 22730454.8)
Hier wird auch auf dieses Dokument verwiesen:
Als Lösung wird dort angeboten:
a) die Berechtigung für die libsqlplus.so manuell wieder auf 644 zu setzen (danach funktioniert auch alles wieder)
b) auf die erste gefixte Version zu gehen (12.2 – vermutlich nicht immer sofort möglich und vielleicht auch etwas übertrieben wegen einer Berechtigung…)
c) nach Installation des PSUs dann noch den Patch 22730454 zu installieren (ja, den gibt’s wirklich, und zwar für Linux x86-64 und einige andere ausgewählte Plattformen, etwas unterschiedlich je nach betroffener Oracle-Version)
Der Patch für 12.1.0.2 ist satte 4,8 KB groß – die Vermutung liegt nah, dass dieser tatsächlich lediglich die eine Berechtigung umsetzt. Ich würde allerdings vermuten, dass es schneller geht, selber chmod 644 auf $ORACLE_HOME/lib/libsqlplus.so auszuführen, als noch einen weiteren Patch herunterzuladen und einzuspielen. Ich habe es jedenfalls so gemacht…
Die aktuelle Erfahrung wurde mit Oracle 12.1.0.2 auf RHEL und dem aktuellen PSU, also Juli 2017, gemacht. Laut den MOS-Artikeln sollen jedoch auch die Versionen ab 11.2.0.4 möglicherweise betroffen sein. Für die Version 12.1.0.1 kann ich das so nicht bestätigen – diese Version mit den PSUs von 07/2017 und 10/2016 auf diversen Linux-Servern hatte dieses Problem jedenfalls nicht – diese ist allerdings in der Bug-Note auch nur als „believed to be affected“ und nicht als „confirmed as being affected“ wie die 11.2.0.4 gelistet.