Init Skript startet nur mit vorangestelltem bash

[DrunkenFreak]

Hallo,

ich versuche den Apache mit dem Modul mod_owa (https://oss.oracle.com/projects/mod_owa/dist/documentation/modowa.htm)[1] unter CentOS 6.6 zu starten. Wenn ich den Apache über

/etc/init.d/httpd start
starte, erhalte ich die Fehlermeldung

httpd: Syntax error on line 202 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/mod_owa.so into server: libclntsh.so.11.1: cannot open shared object file: No such file or directory
Starte ich über

bash /etc/init.d/httpd start
gibt es keine Probleme und der Apache startet wie gewünscht. In der Datei /etc/init.d/httpd habe ich zusätzlich den LD_LIBRARY_PATH für die Oracle Bibliotheken eingepflegt, damit mod_owa diese auch finden kann.

strace gibt mir folgendes bei fehlerhaftem Start:


open("/u01/app/oracle/product/11.2.0/xe/lib/libclntsh.so.11.1", O_RDONLY) = -1 EACCES (Permission denied)


Bei erfolgreichem Start steht dort:


open("/u01/app/oracle/product/11.2.0/xe/lib/libclntsh.so.11.1", O_RDONLY) = 6


Die Datei ist für alle les- und ausführbar, das gleiche gilt für alle darüber liegenden Verzeichnisse.

Die gleiche Konfiguration läuft unter CentOS 6.5 wunderbar.

Hat jemand eine Idee, was hier das Problem sein könnte?


[1]: mod_owa ist ein Apache Modul zur Verbindung mit einer Oracle DB. Es ersetzt das proprietäre mod_plsql.

[gadget]

Könnte es sein, dass in line 202 ein Bash-buildin-Befehl steht? Nur so 'ne Idee...

[DrunkenFreak]

In Zeile 202 der httpd.conf steht:


LoadModule owa_module modules/mod_owa.so


Und file sagt dazu:



mod_owa.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped


Daher nein.

[DrunkenFreak]

Der Apache startet jetzt auch ohne vorangestelltem bash. Schuld war selinux, was noch aktiviert war.

Dennoch würde mich interessieren, warum "bash skript.sh" geht aber "./skript" nicht.

[gadget]

Hm, vielleicht läuft ./skript nicht mit /bin/sh statt mit /bin/bash? Würde das bezüglich selinux einen Unterschied machen?

[DrunkenFreak]

Die Shebang ist #!/bin/bash. "sh skript.sh" und "bash skript.sh" machen hier keinen Unterschied. Probiert habe ich auch, die Shebang zu #!/bin/sh zu ändern. Dies änderte nichts an dem Verhalten.

[gadget]

Was macht es dann noch für einen Unterschied zwischen den beiden Varianten, ein Shell-Skript zu starten? Bei "./skript.sh" startet ein ausführbares Skript eine Shell, bei "bash skript.sh" rufst du eine Shell auf, die die Befehle im Skript abarbeitet.
Hat das einen Einfluss auf selinux?

[DrunkenFreak]

Genau Das frage ich mich ja auch. Eigentlich sollte es egal sein, ob ich das mit Shell starte oder ohne.

Root habe ich auf dem Server und damit auch Einfluss auf selinux, wenn du das meinst.

[gadget]

Na, ich kenne mich mit selinux nicht aus.
Soviel ich verstanden habe, geht es dabei um eine feinere Rechteverteilung. Daher fragte ich mich, ob es bei der Konfiguration deines Systems einen Unterschied macht, ob du als User/Root eine Shell startest oder ob ein Skript das tut.

[nopes]

Vielleicht helfen dir ja die Überlegungen bzgl. selinux in diesem Thread weiter - http://www.linuxforen.de/forums/showthread.php?278022-Firefox-und-Thunderbird-kommen-nicht-ins-Netz

[marce]

vorneweg: ich bin da auch nicht zu 100% fit drin, aber...

Daher fragte ich mich, ob es bei der Konfiguration deines Systems einen Unterschied macht, ob du als User/Root eine Shell startest oder ob ein Skript das tut.
Natürlich macht es da.
SELinux defniert ja sozusagen Kontexte und Regeln, in denen etwas erlaubt ist oder eben nicht.

Was z.B. ein konkreter Unterschied sein könnte, wäre z.B. ob Scripte in /etc/init.d Umgebungsvariablen außerhalb definierter Set-Scripte setzen dürfen oder ob sie auf beliebige Binaries zugreifen dürfen oder nur auf die, die von den entsprechenden Regeln als vertrauenswürdig definiert sind.

Sprich: im Kontext von root->bash ist ggf. anderes erlaubt (sinnvoll, da man ja evtl. eigene Scripte schreiben will) als im Kontext von root->/etc/init.d/* (da soll bitte nichts "einfach so" mehr können als vom System als bekannt und benötigt definiert

Rausfinden, welche Regeln wann wo greifen könnte man z.B. mit http://wiki.gentoo.org/wiki/SELinux/FAQ#How_do_I_know_which_file_context_rule_is_used_ for_a_particular_file.3F - oder eben SELinux auf reporting schalten und dann schauen, was denn "knallt".