Apache2 + suexec Pfad != /srv/www
Hallo, Ich habe hier ein kleines Problem mit unserem "Indianer". Situation: Auf unserem Server im Intranet laufen mehrere "Webseiten". U.a. diverse Kataloge mit technischen Info's, Preislisten usw.. Dazu habe ich ant. einen Apache mit vhosts laufen. Die Config ist "port-based", da ein Port über die Firewall ins www ge-"natted" wird. Eine dieser "Webseite" ist allerdings unser Warenwirtschaftssystem/ ERP (Kivitendo). Dieses ERP besteht im Wesentlichen aus Perl- Scripten, die eine PostgreSQL- Datenbank bedienen. Nun läuft ja unter Apache und openSUSE jeder Host mit dem Nutzer "wwwrun" und Gruppe "www". Da für den Zugriff auf die Postgres- DB aber ein Nutzer notwendig/ gewollt ist, hab ich ein Problem: Da der Postgres- Nutzer und der vhost- Nutzer nicht gleich sind, verweigert Postgres den Zugriff. Deshalb habe ich noch eine extrem unsichere Postgres- Config (pg_hba.conf), wo eigentlich gar kein Passwort notwendig ist (hat zum Glück noch niemand gemerkt bzw. die Nutzer wissen eh nichts damit anzufangen)! Das möchte ich nat. ändern. Dazu wollte ich nun die Apache- Config mit "suexec" für diesen speziellen vhost versehen und die Nutzer gleich machen, damit PostgreSQL nicht mehr meckert. Leider bin ich auf ein neues Problem gestoßen: suexec scheint ein Problem mit dem "DocumentRoot" zu haben. Die Seite funktioniert nicht mehr und in der suexec.log kommt nur sowas: ------------------/var/log/apache2/suexec.log---------------------------- [2014-10-04 00:24:40]: uid: (12345678/kivitendo) gid: (12345/wws) cmd: dispatcher.fpl [2014-10-04 00:24:40]: command not in docroot (/mnt/md1/lvm/srv/www/vhosts/kivitendo-test/dispatcher.fpl) ---------------------------------------------------------------------------------- Natürlich befindet sich die Datei genau dort, wo sie sein soll! Eben im Verzeichnis des vhosts! Nach einigem Suchen im Netz bin ich auf Anleitungen gestoßen, wo man suexec neu kompilieren soll und dort den Pfad angeben soll. Es finden sich aber auch Anleitungen, die von der Datei "/etc/apache2/suexec/wwwdata" sprechen und dass man dort für suexec das "DocumentRoot" angeben kann. Ich finde es n ur reichlich komisch, dass bei suexec der Pfad fest einkompiliert werden muss und nicht über Kondigdateien mitgegeben werden kann. Die Idee, jeden vhost mit einem eigenen Nutzer/ Gruppe laufen zu lassen, würde ich gern umsetzen. Deshalb folgende Fragen: 1. Muss ich suexec mit dem neuen Pfad kompilieren? 2. Kann man mit Yast2 http-server verschiedene vhosts mit unterschiedlichen Nutzern (x- vhosts mit x- verschiedenen Nutzern/ Gruppen) konfigurieren? 3. Gibt es ggf. Alternativen zu suexec, die mit openSuSE/ Yast2 laufen/ konfigurierbar und sicher sind? OS: openSUSE 12.3 (x86_64) Apache: 2.22.x (aus Update- Repo) -- Mit freundlichen Grüßen Sebastian Reinhardt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Sebastian, vorausschicken will ich, dass ich mit solchen Konfigs nur wenig Erfahrung habe. Am Samstag 04 Oktober 2014 schrieb Sebastian Reinhardt: [...]
Leider bin ich auf ein neues Problem gestoßen: suexec scheint ein Problem mit dem "DocumentRoot" zu haben. Die Seite funktioniert nicht mehr und in der suexec.log kommt nur sowas: ------------------/var/log/apache2/suexec.log--------------------- ------- [2014-10-04 00:24:40]: uid: (12345678/kivitendo) gid: (12345/wws) cmd: dispatcher.fpl [2014-10-04 00:24:40]: command not in docroot (/mnt/md1/lvm/srv/www/vhosts/kivitendo-test/dispatcher.fpl) ------------------------------------------------------------------ ----------------
Bist Du sicher, dass der Pfad der Documentroot nicht einen Zweig zu lang ist? Müsste der nicht /mnt/md1/lvm/srv/www/vhosts/kivitendo-test/ heißen? Je nach Lage der Skripten muss auch der cgi-bin-Pfad in der vhost.conf richtig sitzen. Da kann man sich ruckzuck vertun.
Natürlich befindet sich die Datei genau dort, wo sie sein soll! Eben im Verzeichnis des vhosts! Nach einigem Suchen im Netz bin ich auf Anleitungen gestoßen, wo man suexec neu kompilieren soll und dort den Pfad angeben soll. Es finden sich aber auch Anleitungen, die von der Datei "/etc/apache2/suexec/wwwdata" sprechen und dass man dort für suexec das "DocumentRoot" angeben kann. Ich finde es n ur reichlich komisch, dass bei suexec der Pfad fest einkompiliert werden muss und nicht über Kondigdateien mitgegeben werden kann. Die Idee, jeden vhost mit einem eigenen Nutzer/ Gruppe laufen zu lassen, würde ich gern umsetzen.
Soweit ich das verstanden habe, bezieht sich der Benutzerwechsel nur auf die auszuführenden Skripte und haben nichts damit zu tun, wo die Dateien des Programms wie kivitendo oder eines CMS liegen. Also, in dem Moment, wo der Apache ein cgi-Skript ausführen soll, wechselt das Skript vom Apachen auf den Eigentümer des Skriptes. Dieser hat dann nur seine eigenen Rechte und nicht die des Apachen.
Deshalb folgende Fragen:
1. Muss ich suexec mit dem neuen Pfad kompilieren?
Glaube ich nicht. (Ich weiß allerdings grad nicht, ob bei mir suexec aktiv ist). Die Documentroot, auf der ich rummansche, gehört mir übrigens selbst, damit ich als Benutzer helga:helga da drin rummosten kann. (Meistens Testinstallationen von CMS). (Damit das hinterher läuft, bin ich selbst in der Gruppe www. Dann kann der Apache auch alles ausführen, was da drin liegt. Meine Documentroot lautet übrigens auf: /srv/webentwicklung/meinevhosts. Da drunter läuft ein bunter Strauß von PHP- und Perlkrams).
2. Kann man mit Yast2 http-server verschiedene vhosts mit unterschiedlichen Nutzern (x- vhosts mit x- verschiedenen Nutzern/ Gruppen) konfigurieren?
Mach's zu Fuss.
3. Gibt es ggf. Alternativen zu suexec, die mit openSuSE/ Yast2 laufen/ konfigurierbar und sicher sind?
Die Alternative heißt fastcgi, meine. (Ich habe aber nicht mehr parat, warum ich mich dagegen entschieden hatte). Helga -- ## Technik: [http://de.opensuse.org] ## Privat: [http://www.eschkitai.de] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Sebastian,
vorausschicken will ich, dass ich mit solchen Konfigs nur wenig Erfahrung habe.
Am Samstag 04 Oktober 2014 schrieb Sebastian Reinhardt:
[...]
Leider bin ich auf ein neues Problem gestoßen: suexec scheint ein Problem mit dem "DocumentRoot" zu haben. Die Seite funktioniert nicht mehr und in der suexec.log kommt nur sowas: ------------------/var/log/apache2/suexec.log--------------------- ------- [2014-10-04 00:24:40]: uid: (12345678/kivitendo) gid: (12345/wws) cmd: dispatcher.fpl [2014-10-04 00:24:40]: command not in docroot (/mnt/md1/lvm/srv/www/vhosts/kivitendo-test/dispatcher.fpl) ------------------------------------------------------------------ ---------------- Bist Du sicher, dass der Pfad der Documentroot nicht einen Zweig zu lang ist? Müsste der nicht /mnt/md1/lvm/srv/www/vhosts/kivitendo-test/ heißen? Heist der ja! suexec meint, dass das Script "dispatcher.fpl" nicht dort
Am 04.10.2014 um 20:01 schrieb Helga Fischer: liegen würde! Tut es aber! Ich habe alle Webseiten auf eine andere Partition/ Platte gelegt (/mnt/md1, früher mal /mnt/lvm/; alles von "lvm" hab ich später auf das Raid verschoben und "lvm" noch beibehalten bzw. einen symb. Link gesetzt, sollte aber eigentlich Wurscht sein, wo das liegt, so lange die Pfade "absolut" und korrekt sind?)
Je nach Lage der Skripten muss auch der cgi-bin-Pfad in der vhost.conf richtig sitzen. Da kann man sich ruckzuck vertun.
Ohne "suexec" funktioniert die Config des vhosts ja! Ich habe nur die Zeile "SuexecUserGroup kivitendo wws" eingefügt! Bei "kivitendo" ist i.Ü. der "html"- und der "cgi"-Pfad identisch!
Natürlich befindet sich die Datei genau dort, wo sie sein soll! Eben im Verzeichnis des vhosts! Nach einigem Suchen im Netz bin ich auf Anleitungen gestoßen, wo man suexec neu kompilieren soll und dort den Pfad angeben soll. Es finden sich aber auch Anleitungen, die von der Datei "/etc/apache2/suexec/wwwdata" sprechen und dass man dort für suexec das "DocumentRoot" angeben kann. Ich finde es n ur reichlich komisch, dass bei suexec der Pfad fest einkompiliert werden muss und nicht über Kondigdateien mitgegeben werden kann. Die Idee, jeden vhost mit einem eigenen Nutzer/ Gruppe laufen zu lassen, würde ich gern umsetzen. Soweit ich das verstanden habe, bezieht sich der Benutzerwechsel nur auf die auszuführenden Skripte und haben nichts damit zu tun, wo die Dateien des Programms wie kivitendo oder eines CMS liegen. Also, in dem Moment, wo der Apache ein cgi-Skript ausführen soll, wechselt das Skript vom Apachen auf den Eigentümer des Skriptes. Dieser hat dann nur seine eigenen Rechte und nicht die des Apachen.
Deshalb folgende Fragen:
1. Muss ich suexec mit dem neuen Pfad kompilieren? Glaube ich nicht. (Ich weiß allerdings grad nicht, ob bei mir suexec aktiv ist).
Die Documentroot, auf der ich rummansche, gehört mir übrigens selbst, damit ich als Benutzer helga:helga da drin rummosten kann. (Meistens Testinstallationen von CMS). (Damit das hinterher läuft, bin ich selbst in der Gruppe www. Dann kann der Apache auch alles ausführen, was da drin liegt. Meine Documentroot lautet übrigens auf: /srv/webentwicklung/meinevhosts. Da drunter läuft ein bunter Strauß von PHP- und Perlkrams).
2. Kann man mit Yast2 http-server verschiedene vhosts mit unterschiedlichen Nutzern (x- vhosts mit x- verschiedenen Nutzern/ Gruppen) konfigurieren? Mach's zu Fuss. Das Meiste ändere ich eh so. Aber ich möchte eben so eventuelle Tipp- und Verständnisfehler ausschließen (und mich auf die Entwickler verlassen ). Deshalb nehme ich die Yast2 generierten Dateien immer als Vorlage....
3. Gibt es ggf. Alternativen zu suexec, die mit openSuSE/ Yast2 laufen/ konfigurierbar und sicher sind? Die Alternative heißt fastcgi, meine. (Ich habe aber nicht mehr parat, warum ich mich dagegen entschieden hatte). Na das "fastcgi"- Modul ist für "Kivitendo" eh obligatorisch, aber kann man dort auch den Nutzer ändern?
Helga
Also lieber noch mal: Mein Problem ist eigentlich nicht "Suexec2",
sondern dass Postgres merkt, dass der Nutzer "wwwrun" sich mit dem
Nutzernamen "kivitendo" an der DB anmelden will und das nat. zwei
unterschiedliche Nutzer sind. Deshalb würde ich gern nur (!) den vhost
"Kivitendo" mit dem Nutzer "kivitendo" statt "wwwrun" ausführen. Es geht
dabei nicht um die Verzeichnisberechtigungen des Scriptverzeichnisses!
Hier mal Vorschsthalber meine vhosts- Config:
---------------/etc/apache2/vhosts/kivitendo-test.nas.conf------------------------
--------------/var/lib/pgsql/data/pg_hba.conf----------------------------------
# kivitendo unsecure # # # local is for Unix domain socket connections only local all all trust # IPv4 local connections: host all all 127.0.0.1/32 trust # IPv6 local connections: host all all ::1/128 trust host all all 127.0.0.1 255.255.255.255 trust ---------------/var/lib/pgsql/data/pg_hba.conf----------------------------------
-- Mit freundlichen Grüßen
Sebastian Reinhardt
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 04.10.2014 20:39, schrieb Sebastian Reinhardt:
Hallo Sebastian,
vorausschicken will ich, dass ich mit solchen Konfigs nur wenig Erfahrung habe.
Am Samstag 04 Oktober 2014 schrieb Sebastian Reinhardt:
[...]
Leider bin ich auf ein neues Problem gestoßen: suexec scheint ein Problem mit dem "DocumentRoot" zu haben. Die Seite funktioniert nicht mehr und in der suexec.log kommt nur sowas: ------------------/var/log/apache2/suexec.log--------------------- ------- [2014-10-04 00:24:40]: uid: (12345678/kivitendo) gid: (12345/wws) cmd: dispatcher.fpl [2014-10-04 00:24:40]: command not in docroot (/mnt/md1/lvm/srv/www/vhosts/kivitendo-test/dispatcher.fpl) ------------------------------------------------------------------ ---------------- Bist Du sicher, dass der Pfad der Documentroot nicht einen Zweig zu lang ist? Müsste der nicht /mnt/md1/lvm/srv/www/vhosts/kivitendo-test/ heißen? Heist der ja! suexec meint, dass das Script "dispatcher.fpl" nicht dort
Am 04.10.2014 um 20:01 schrieb Helga Fischer: liegen würde! Tut es aber! Ich habe alle Webseiten auf eine andere Partition/ Platte gelegt (/mnt/md1, früher mal /mnt/lvm/; alles von "lvm" hab ich später auf das Raid verschoben und "lvm" noch beibehalten bzw. einen symb. Link gesetzt, sollte aber eigentlich Wurscht sein, wo das liegt, so lange die Pfade "absolut" und korrekt sind?)
Hi,
vielleicht liegt hier der Hund begraben: Symbolische Links muss man für
das Verzeichnis, in dem der Link liegt explizit erlauben, sie sind
standardmässig (aus Sicherheitsgründen) nicht erlaubt.
Am 04.10.2014 um 18:13 schrieb Sebastian Reinhardt:
Deshalb folgende Fragen:
1. Muss ich suexec mit dem neuen Pfad kompilieren? Damit jeder PHP-Prozess auf meinen Webserver von einem eigenen User ausgeführt wird, habe ich vor Jahren mit fcgid, suexec und php5_modfcgid angefangen. Der Pfad war damals von außen nicht konfigurierbar. Kann gut sein, dass das immer noch so ist. Du kannst ja testhalber die Partition mal dorthin mounten bzw. das Verzeichniss hinkopieren. /usr/sbin/suexec2 -V zeigt übrigens an wie der Pfad sein soll.
Gruß Ingo -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 05.10.2014 um 11:02 schrieb Ingo:
Deshalb folgende Fragen:
1. Muss ich suexec mit dem neuen Pfad kompilieren? Damit jeder PHP-Prozess auf meinen Webserver von einem eigenen User ausgeführt wird, habe ich vor Jahren mit fcgid, suexec und
Am 04.10.2014 um 18:13 schrieb Sebastian Reinhardt: php5_modfcgid angefangen. Der Pfad war damals von außen nicht konfigurierbar. Kann gut sein, dass das immer noch so ist. Du kannst ja testhalber die Partition mal dorthin mounten bzw. das Verzeichniss hinkopieren. /usr/sbin/suexec2 -V zeigt übrigens an wie der Pfad sein soll.
Gruß Ingo
Hallo, Ja das war mein nächster Schritt (alles nach /srv/www/vhosts/kivitendo/... kopieren), das noch mal zu probieren. Wie erwartet funktioniert das natürlich. Es scheint also, dass "suexec" die Einstellungen derart "hardcodiert" sind, dass nur eine komplette Umstellung der Verzeichnisorganisation oder neu kompilieren von "suexec" als Lösung bleibt. Das ist eher "linux-untypisch".....es lässt sich doch sonst fast alles in Textdateien konfigurieren..... :-( Ich werde das noch mal mit "Hardlinks" probieren. Mal schauen... -- Mit freundlichen Grüßen Sebastian Reinhardt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, Am Sun, 05 Oct 2014, Sebastian Reinhardt schrieb:
Am 05.10.2014 um 11:02 schrieb Ingo:
1. Muss ich suexec mit dem neuen Pfad kompilieren? Damit jeder PHP-Prozess auf meinen Webserver von einem eigenen User ausgeführt wird, habe ich vor Jahren mit fcgid, suexec und
Am 04.10.2014 um 18:13 schrieb Sebastian Reinhardt: php5_modfcgid angefangen. Der Pfad war damals von außen nicht konfigurierbar. Kann gut sein, dass das immer noch so ist. Du kannst ja testhalber die Partition mal dorthin mounten bzw. das Verzeichniss hinkopieren. /usr/sbin/suexec2 -V zeigt übrigens an wie der Pfad sein soll. [..] Ja das war mein nächster Schritt (alles nach /srv/www/vhosts/kivitendo/... kopieren), das noch mal zu probieren. Wie erwartet funktioniert das natürlich. Es scheint also, dass "suexec" die Einstellungen derart "hardcodiert" sind, dass nur eine komplette Umstellung der Verzeichnisorganisation oder neu kompilieren von "suexec" als Lösung bleibt. Das ist eher "linux-untypisch".....es lässt sich doch sonst fast alles in Textdateien konfigurieren..... :-(
Ich werde das noch mal mit "Hardlinks" probieren. Mal schauen...
Hardlinks gehen nicht auf Verzeichnissen. Nimm 'bind-mounts' (das klappt auch mit systemd, unter 13.1 in ner VM vorgestern oder so getestet): # mkdir -p /srv/www/vhosts/kivitendo ==== /etc/fstab [Eintrag auf eine Zeile ohne den '\'] ==== /mnt/md1/lvm/srv/www/vhosts/kivitendo-test \ /srv/www/vhosts/kivitendo none bind 0 0 ==== HTH, -dnh -- Treat your password like your toothbrush. Don't let anybody else use it, and get a new one every six months. -- Clifford Stoll [found in ssl_engine_pphrase.c] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 06.10.2014 um 19:06 schrieb David Haller:
Hallo,
Am Sun, 05 Oct 2014, Sebastian Reinhardt schrieb:
[..]
Ja das war mein nächster Schritt (alles nach /srv/www/vhosts/kivitendo/... kopieren), das noch mal zu probieren. Wie erwartet funktioniert das natürlich. Es scheint also, dass "suexec" die Einstellungen derart "hardcodiert" sind, dass nur eine komplette Umstellung der Verzeichnisorganisation oder neu kompilieren von "suexec" als Lösung bleibt. Das ist eher "linux-untypisch".....es lässt sich doch sonst fast alles in Textdateien konfigurieren..... :-(
Ich werde das noch mal mit "Hardlinks" probieren. Mal schauen... Hardlinks gehen nicht auf Verzeichnissen. Nimm 'bind-mounts' (das klappt auch mit systemd, unter 13.1 in ner VM vorgestern oder so getestet):
# mkdir -p /srv/www/vhosts/kivitendo
==== /etc/fstab [Eintrag auf eine Zeile ohne den '\'] ==== /mnt/md1/lvm/srv/www/vhosts/kivitendo-test \ /srv/www/vhosts/kivitendo none bind 0 0 ====
HTH, -dnh
Ja, die Hardlinks gehen nicht. Hatte das nicht mehr so präsent, aber Linux hat mich wieder daran erinnert. Ich habe mich schon mit dem Kompilieren abgefunden. Aber Dein Vorschlag klingt "schneller" und "einfacher". Werde das morgen probieren. Danke. -- Mit freundlichen Grüßen Sebastian Reinhardt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (5)
-
David Haller -
Helga Fischer -
Ingo -
Joerg Thuemmler -
Sebastian Reinhardt