Oracle OHS - Automatische Anmeldung an Weblogic

Das Starten eines Servers bzw. einer Komponente eines Weblogic-Servers ist mit einer Kennworteingabe verbunden.

./startComponent.sh ohs1

Um nicht jedes Mal wieder das Kennwort angeben zu müssen, kann man dieses "permanent" speichern.

./startComponent.sh ohs1 storeUserConfig

Creating the key file can reduce the security of your system if it is not kept in a secured location after it is created. Creating new key... The username and password that were used for this WebLogic NodeManager connection are stored in /home/oracle/.wlst/nm-cfg-ohs1.props and /home/oracle/.wlst/nm-key-ohs1.props.

Die ausgegebene Meldung bestätigt den Fakt, dass die Konfiguration und der Schlüssel (für die Anmeldung) im Verzeichnis "/home/oracle/.wlst" gespeichert wurde.

Nun lässt sich tatsächlich die Server-Komponente Starten und Stoppt, ohne dass erneut nach dem Kennwort gefragt wird. - Es steht also einem automatischem Start durch "systemd" nichts mehr im Wege. ...sollte man sich denken. Denn, nach dem Start des Betriebssystems fehlt plötzlich das Verzeichnis "/home/oracle/.wlst" wieder. Natürlich zweifelt man zuerst am eigenen Verstand, muss sich dann doch recht bald eingestehen, dass da mal wieder etwas so läuft, wie es nicht laufen sollte. Wer oder was löscht einfach so dieses Verzeichnis mit der Konfiguration und dem Schlüssel und vermasselt die automatische Anmeldung? Klar handelt es sich bei diesem Verfahren nicht um den schönsten Weg, aber ich bin der Administrator! - Ich entscheide darüber, was richtig und was falsch ist!!!

Zuerst hatte ich etwas übereifrige Helfer wie Puppet im Hinterkopf, aber eine fehlerhafte Konfiguration wäre irgendwie auch wieder zu naheliegend. Da ich bereits die Ahnung - fußend auf schlechten Erfahrungen - hatte, dass es von Oracle selbst kommen könnte, entschied ich mich das blinde Herumstochern in eine handfeste Beweisführung zu überführen.

Ich schalte das Auditing ein und gucke mir den Systemstart etwas genauer an: tune2fs -l /dev/sda1| grep acl

Default mount options: user_xattr acl

Gut, es ist für die Partition aktiviert. Nun, so der Dienst nicht ohnehin läuft, kann eben dieser aktiviert werrden. systemctl enable auditd

Die Überwachung des Verzeichnisses wird wie folgt aktiviert: auditctl -w /home/oracle/.wlst

Nun kann man sich die Einträge anzeigen lassen: ausearch -f /home/oracle/.wlst

type=PATH msg=audit...nametype=DELETE type=PATH msg=audit...item=0 name="/home/oracle/.wlst/"... type=CWD msg=audit...cwd="/" type=SYSCALL msg=audit...comm="java" exe="/u01/app/oracle/owt12/oracle_common/jdk/jre/bin/java" key=(null)

type=PATH msg=audit...nametype=DELETE type=PATH msg=audit...item=0 name="/home/oracle/.wlst/"... type=CWD msg=audit...cwd="/" type=SYSCALL msg=audit...comm="java" exe="/u01/app/oracle/owt12/oracle_common/jdk/jre/bin/java" key=(null)

So, damit ist der Schuldige identifiziert und bestätigt abermals die schlechte Erfahrung. Keine Frage, es handelt sich dabei um den Versuch "Sicherheit" herzustellen, aber... Och komm' schon! Dem Nutzer "oracle" gehört der Server. Wer, sollte sich den Schlüssel aus seinem Home stehlen? ...etwa "root"?

Weil ich - mal wieder - anderer Meinung bin, ist die Lösung auch eben ein Meinungsverstärker. Das Verzeichnis "/home/oracle/.wlst" und dessen Dateien gehörem natürlich dem Nutzer "oracle"; und das möchte ich nicht verändern. Also immunisiere ich doch einfach die Dateien, so dass diese eben nicht mehr so ohne weiteres gelöscht werden können.

chattr +i /home/oracle/.wlst
chattr +i /home/oracle/.wlst/*

Keine schöne Lösung, aber eine Lösung, die der Ursache entspricht. - Du löscht unerlaubt MEINE Daten und ich verbiete es dir!

Nachtrag:
Diese Dateien müssen, will man sie irgendwann wieder löschen, wieder "de-immunisiert" werden; mittels des Schalters "-i".