Bei mir läuft PHP als DSO. Daher kann mein Installationsskript (das in eine Konfigurationsdatei schreibt) nichts schreiben.
Wie gebe ich Apache (Benutzer: niemand) die Möglichkeit, in die Datei zu schreiben?
Antwort1
Ich würde dies nur auf einem Entwicklungsserver in einer sicheren Umgebung tun. Viele PHP-Anwendungen generieren die Datei auf dem Bildschirm, sodass sie sicher in das Konfigurationsverzeichnis kopiert werden kann.
Der schnelle (und unsichere) Weg, dies zu tun, besteht darin, es chmod 777 .aus dem Verzeichnis auszuführen, in das die Datei gehen soll. Führen Sie vorher einen Befehl aus, ls -ld .um die Berechtigungen abzurufen, auf die Sie sie zurücksetzen möchten. In einigen Fällen existiert das erforderliche Verzeichnis nicht, sodass Sie es zuerst erstellen müssen. Setzen Sie das Verzeichnis sofort nach dem Schreiben der Konfigurationsdatei auf seine ursprünglichen Berechtigungen zurück. Der richtige Befehl wird wahrscheinlich chmod 755 .oder chmod 750 .aus dem Verzeichnis ausgeführt. Überprüfen Sie dies mit dem Befehl ls.
Ändern Sie die Berechtigungen für die Konfigurationsdatei, sodass Apache nicht mehr in sie schreiben kann ( chmod o-w configfile). Anwendungen werden oft mit Beispielkonfigurationsdateien geliefert. Eine dieser Dateien im Konfigurationsverzeichnis abzulegen und zu bearbeiten, ist möglicherweise eine bessere Vorgehensweise. Dazu müssen Sie die Konfigurationsoptionen kennen und verstehen. Möglicherweise können Sie das Online-Konfigurationsskript zur Unterstützung Ihrer Änderungen verwenden.
Antwort2
Sie können Ihre Konfigurationsdateien in einem temporären Verzeichnis wie schreiben /tmp/config/. Anschließend können Sie ein Shell-Skript ausführen, um die Konfigurationsdateien an /tmp/config/den gewünschten Speicherort zu kopieren.
Um die erforderlichen Berechtigungen zu erteilen, können Sie den Benutzer nobodyzur sudoers-Datei hinzufügen. Der Eintrag sollte folgendermaßen aussehen:
nobody ALL=NOPASSWD: /path/to/your_script.sh
Das Shell-Skript (vergessen Sie nicht, die Ausführungsberechtigung hinzuzufügen).
cp -r /tmp/config/* /desired/path/to/config
In PHP benötigen Sie einen kleinen Codeausschnitt wie:
<?php
$output = shell_exec('sudo /path/to/your_script.sh');
echo "$output";
?>
Antwort3
In einer gemeinsam genutzten Umgebung wird alles etwas komplizierter, wenn es um Sicherheitsbedenken geht. Indem Sie den Dateieigentümer auf „niemand“ ändern, erteilen Sie Apache Schreibzugriff auf diese Datei. Wenn das PHP-Modul jedoch keine Einstellungen hat, um jeden virtuellen Host auf sein eigenes Verzeichnis zu beschränken, würde es auch anderen Zugriff darauf erteilen. Überprüfen Sie, wie es in Ihrer Umgebung eingerichtet ist.
Apache wird normalerweise als Benutzer „nobody“ und Gruppe „nobody“ ausgeführt, Sie können also auch mit Gruppenberechtigungen experimentieren. Ändern Sie die Gruppe der Datei in „nobody“ und setzen Sie die Berechtigung auf 664.
Wenn Sie den Eigentümer oder die Gruppe der Datei nicht ändern können, können Sie die Berechtigungen normalerweise über FTP ändern. Vorausgesetzt, dass Apache nicht zu dem Benutzer/der Gruppe gehört, dem/der die Datei gehört, müssten Sie den Wert auf 777 setzen, was sehr unsicher ist, aber alles hängt von der Art der Umgebung ab, in der Sie sich befinden. Vielleicht können Sie den Wert vorübergehend festlegen, Ihre App installieren und ihn wieder auf 644 oder 444 (schreibgeschützt) ändern.
Antwort4
Dies ist das typische Problem beim Ausführen von PHP als DSO mit cPanel, es gilt aber auch für andere Setups.
Bei der Ausführung dieser Methode werden PHP-Prozesse von dem Benutzer verwaltet, der httpd ausführt. In den meisten Fällen ist dieser Benutzer der „nobody“-Benutzer. Das bedeutet, wenn PHP mit Dateien im Dateisystem interagiert, müssen diese für den „nobody“-Benutzer zugänglich sein. Dies führt zu Berechtigungsproblemen, da Ihr normaler cPanel-basierter Benutzer ohne die richtigen Berechtigungsänderungen keinen Zugriff auf RW-Dateien (Lesen/Schreiben) hat, die dem „nobody“-Benutzer gehören. Die meisten PHP-Webanwendungen/-Skripte müssen in Dateien und Verzeichnisse schreiben, und wenn sie dem cPanel-Benutzer gehören, führt dies zu Problemen und in einigen Fällen zum Absturz Ihrer Website(s), wenn Sie die Berechtigungen für die Dateien/Verzeichnisse nicht auf 777 ändern.
In diesem Fall können Sie die Berechtigungen einfach manuell verwalten und sie auf 777 setzen.
Wenn Sie diese PHP-Methode ausführen, müssen Sie die Berechtigungen für jeden Benutzer manuell verwalten, um sicherzustellen, dass Ihre PHP-Apps/-Skripte die für ihre Funktion erforderlichen Dateien und Verzeichnisse lesen und in diese schreiben können.
Oder noch besser: Wenn Sie zu Mod_SuPHP wechseln können und keine Leistungsprobleme haben (da DSO viel schneller ist), können Sie PHP als der Benutzer ausführen, der cPanel verwendet.
Wenn wir die Berechtigungsprobleme außer Acht lassen, die beim Ausführen von PHP über DSO auftreten können, hat es im Vergleich zu SuPHP einige Vorteile. Der erste ist die Geschwindigkeit. Mod_PHP ist schneller als Mod_SuPHP. Dies liegt hauptsächlich daran, dass jede von Mod_SuPHP verarbeitete Anfrage so konfiguriert wird, dass sie als der Benutzer ausgeführt wird, dem die Dateien gehören. Dies ist auf Websites mit geringerem Datenverkehr möglicherweise nicht sehr auffällig, kann sich jedoch auf Websites mit höherem Datenverkehr ziemlich schnell summieren. Der zweite Vorteil ist die volle Funktionalität mit PHP-Optcode-Caching-Ergänzungen wie eAcclerator, APC und Xcache. Um den vollen Nutzen eines PHP-Optcode-Caches zu erzielen, benötigen Sie einen gemeinsamen Benutzer, der beim Zwischenspeichern des kompilierten PHP-Bytecodes verwendet wird, und das Ausführen von PHP über ein DSO, bei dem PHP als „Nobody“-Benutzer ausgeführt wird, erfüllt diesen Zweck. Sie können feststellen, ob Ihr Server für die Ausführung von PHP über ein DSO eingerichtet ist, indem Sie zum WHM gehen und unter „Main“ >> „Service Configuration“ >> „Apache Configuration“ nachsehen. >> „PHP and SuExec Configuration“
Hier finden Sie weitere Details:
https://helpdesk.wiredtree.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=1663