php Dateien können nicht per ftp geändert werden

S

stefkey

Member
Hallo,

ich habe php als apache Modul laufen.
Von php-Scripten erzeugte Files können nicht von mir per sftp geändert werden.
Was kann ich tun damit auch das funktioniert?

Grüße, stefkey
 
Vielen Dank virtual2!

Auf die schnelle wäre ja sicher mpm-itk einfacher zu aktivieren, oder?

Kann ich einfach mit
Code: 
apt-get install apache2-mpm-itk libapache2-mod-php5

und einem apache2 restart mpm-itk aktivieren?

Laufen dann die Webseiten (2 cms Webseiten und ein Forum) ohne weiteres zuerst mal und kann ich in Ruhe nach und nach die virtualhosts mit den Usern ergänzen (AssignUserID user1 user1)?
 
Vielen Dank! Es hat prima geklappt.

Zum testen würde ich geren mal mit php zB eine Datei im Browser anzeigen welche im erlaubten Verzeichnis ist und im Gegesatz dazu welche im nicht erlaubten Verzeichnis ist.

Wie stell ich das an?

Ich habe nun mal eine sss.php mit folgendem Inhalt erstellt:
Code: 
<?php
$datei = fopen("irgendwas.txt","r");
echo "$datei";
?>

Da wird aber im Browser bei Aufruf von der sss.php nur eine leere Seite angezeigt. In irgendwas.txt steht nur: Hallo!

Geht das nicht so einfach oder hab ich einen Fehler im php-code?
 
Hast du die Warnungen bei PHP abgeschaltet? Bist du sicher, dass das fopen funktioniert? Irgendwo open_basedir falsch gesetzt? Userid in vhost-Konfig passt nicht zu Verzeichnisrechten.
 
hmm... ich habe mir den Code zusammengebastelt. Ich habe eigentlich keine Ahnung von php. fopen öffnet und liest doch dateien, darum fopen.

Ich habe zuerst mal beide Dateien in /var/www abgelegt. Die Recht sind 644 das reicht doch - es muss doch nur gelesen werden von www-data, oder?
 
Ich habs:

ich nehm einfach:

Code: 
<?php
$irgendwas = file_get_contents('irgendwas.txt');
echo $irgendwas;
?>

DANKE
 
Du musst bei fopen schon einen Pfad mit angeben.
Und wenn fopen fehlschlägt, sollte eigentlich eine Warnung gezeigt werden bzw. im Log stehen. Hast du im VHost- bzw. Errorlog des Apache nachgesehen?
 
hmm danke GwenDragon. Deine Links werde ich gleich nochmal anschauen.

Nun aber zum Problem zurück:
Wenn ich nun per sftp diesen php-Schnipsel in mein vhostroot verschiebe, dann sollte ich doch durch mpm-itk keine Datei außerhalb des diesem vhost im Browser anzeigen können oder?

Ich habe folgenden php-Code:
Code: 
<?php
$homepage = file_get_contents('/var/log/dpkg.log.1');
echo $homepage;
?>

Es zeigt mir die log Datei aber an! Das sollte doch nicht sein, oder?
 
Wenn der Apache als root läuft erben die Vhosts bei mpm_itk dessen Rechte, falls nicht explitzit anders gesetzt.

Welche Dateirechte bei /var/log/dpkg.log.1 ?
Welcher UserID zugewiesen im Vhost (Stichwort: AssignUserId)?
open_basedir aktiviert?
 
Last edited by a moderator:
Die log Datei hat 644.
die AssignUserID ist vergeben, sagen wir user1. Wenn ich per sftp in diesen vhost eine Datei hochlade gehört diese auch user1, wenn ich mit php in diesem vhost eine Datei hochlade gehört sie auch user1, also mpm-itk funktioniert.

Ich dachte nun kann durch Verwendung von mpm-itk außerhalb dieses vhost Verzeichnisses nichts mehr anzeigen lassen. Die log- Datei zB zeigst mir aber, genauso kann ich auch den Inhalt einer config.php Datei aus einem anderen vhost im Browser ausgeben.
Hat das was mit Base opendir noch weiter zutun?
 
0644 heißt: Lesen+Schreibe für root, für Gruppe und Welt lesbar, also kann auch user1 die lesen.

ITK MPM lässt nur den Vhost-Prozess unter einer eigenen UID/GID laufen, von Restriktionen in Bezug auf Module wie mod_php kann ich nichts finden.

//EDIT:
Soweit ich mich erinnere läuft mod_php als Prozess mit sehr hohen Rechten, deswegen braucht es ja Restriktionen wie open_basdir.

//EDIT2: Ausführlich erklären muss es dir jemand anders. So weit blick ich da nicht rein ;)
 
Last edited by a moderator:
Okay, danke mal! Ich muss mich auch nochmal "schlau" machen.
Ich werde dann ggf. Einen eigenen Thread dafür öffnen wenn es fragen gibt. Die ursprüngliche Fragestellung ist ja auch beantwortet. Vielen Dank Gr deine Mühe!
 
Soweit ich mich erinnere läuft mod_php als Prozess mit sehr hohen Rechten, deswegen braucht es ja Restriktionen wie open_basdir.
Click to expand...
Mod-PHP ist kein separater Prozess (nicht mal ein separater Thread) sondern ein Teil des Apache-Prozesses welcher von ITK geforkt wird. Er hat exakt die Rechte des Benutzers welcher ITK dem Prozess zuweist. Generell darf ein Unix-User auf alle Dateien zugreifen deren CHMOD-Rechte es zulassen.


Ich dachte nun kann durch Verwendung von mpm-itk außerhalb dieses vhost Verzeichnisses nichts mehr anzeigen lassen. Die log- Datei zB zeigst mir aber, genauso kann ich auch den Inhalt einer config.php Datei aus einem anderen vhost im Browser ausgeben.
Click to expand...
Falls du nur auf PHP und keine weitere Sprachen setzt so ist die Verwendung von open_basedir die bequemste und einfachste Lösung um einzelne Domains oder Ordner auf getrennte Pfade zu begrenzen. Beachte aber dass durch die Verwendung von open_basedir die PHP-Curl Erweiterung begrenzt ist was bspw mit Owncloud Probleme macht. Lässt sich zwar über auto_prepend_file und mit der runkit-Extension quick&dirty-patchen aber naja... :D

Eine alternative aber unflexiblere Lösung wäre mod_chroot und mod_security in Verbindung mit SecChrootDir wobei Letzterer weniger Probleme mit externen Libraries des Apache-Prozesses zu haben scheint.
 
oh, danke d4f für deine Ausführungen.

Ich habe nun open_basedir gesetzt. Und zwar in der apache vhost:

Wo ist es richtiger aufgehoben? Innerhalb oder außerhalb <Directory>?

Mit einer .htaccess kann man ja php_Werte überschreiben. Ich möchte das testen. Ich habe nun eine .htaccess mit dem Einzeiler php_admin_value open_basedir / . Im errorlog steht nun /var/www/blah/2014/.htaccess: php_admin_value not allowed here. Kannst du etwas dazu sagen? Es liegt sicher am AllowOverride, oder?

Code: 
<VirtualHost *:80>
        ServerName blah.de
        ServerAlias blah.blah.de
        ServerAdmin blah@blah.de
        DocumentRoot /var/www/blah/2014
        <Directory /var/www/blah/2014>
                Options Indexes FollowSymLinks MultiViews
                Options -All +FollowSymLinks
                AllowOverride AuthConfig FileInfo
                Order allow,deny
                allow from all
php_admin_value open_basedir /var/www/blah/2014
        </Directory>

#php_admin_value open_basedir /var/www/blah/2014

        ErrorLog ${APACHE_LOG_DIR}/error_blah.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel error

        CustomLog ${APACHE_LOG_DIR}/access_blah.log combined

  <IfModule mpm_itk_module>
    AssignUserId user1 grou11
    MaxClientsVHost 50
    NiceValue 10
  </IfModule>


</VirtualHost>
 
Wo ist es richtiger aufgehoben? Innerhalb oder außerhalb <Directory>?
Click to expand...
Das ist abhängig was du realisieren willst, beides ist gültig.
Ausserhalb des Directory würde ich für einen "Standard"-Wert je vHost empfehlen, weitere Einschränkungen oder Lockerungen je nach Bedarf dann via Directory-Regeln falls bestimmte Programme andere Einstellungen wollen/brauchen.

Im errorlog steht nun /var/www/blah/2014/.htaccess: php_admin_value not allowed here.
Click to expand...
Die Befehle php_admin_value und php_admin_flag dürfen NUR in der Server-Konfiguration verwendet werden. Für .htaccess gibt es die Befehle php_value und php_flag
Der Name deutet bereits darauf hin dass Letzterer für Kunden und die _admin_ für die Sysadmins gedacht ist.

Mit einer .htaccess kann man ja php_Werte überschreiben. Ich möchte das testen.
Click to expand...
Nicht alle Werte können überschrieben werden. Die PHP-Dokumentation muss spezifisch PERDIR für die jeweilige Option auflisten damit es funktioniert.
Hier kommt zusätzlich eine sehr nützliche Eigenschaft von mod_php raus;
Wenn du in der Server-Konfiguration mittels php_admin_value oder php_admin_flag einen Wert setzt kann der Benutzer diesen nicht überschreiben auch wenn PERDIR eigentlich für die Option zugelassen ist.
Dies erlaubt es sicherheits-/performance-relevante Einstellungen ohne böse "Hacks" zu setzen und blockieren.
Falls du nur einen vhost-spezifischen Standardwert setzen willst der überschreibbar ist musst du php_value/php_flag in der Konfiguration verwenden.
 
okay. Danke, viel Mühe machst du dir hier im Forum. Aber ich habe auch viel gelernt! DANKE!

d4f said:
...
Nicht alle Werte können überschrieben werden. Die PHP-Dokumentation muss spezifisch PERDIR für die jeweilige Option auflisten damit es funktioniert.
Click to expand...

Ist das folgende die Liste wo in der 3. Spalte dann PERDIR stehen muss, also genaugenommen PHP_INI_PERDIR
http://www.php.net/manual/de/ini.list.php

d4f said:
...
Wenn du in der Server-Konfiguration mittels php_admin_value oder php_admin_flag einen Wert setzt kann der Benutzer diesen nicht überschreiben auch wenn PERDIR eigentlich für die Option zugelassen ist.
Dies erlaubt es sicherheits-/performance-relevante Einstellungen ohne böse "Hacks" zu setzen und blockieren.
Falls du nur einen vhost-spezifischen Standardwert setzen willst der überschreibbar ist musst du php_value/php_flag in der Konfiguration verwenden.
Click to expand...
Kann auch eine "vhost-php.ini" den globalen Wert auch nicht überschreiben? Also php_admin_value kann ausschließlich nur in der globalen php.ini verwendet werden und wenn dort gesetzt dann ist das auch nicht Änderbar, okay. Danke!

Prima Sache!

Für einige Werte benötige ich wohl eine vhost spezielle php.ini, zB für exec. Denn open_basedir macht ja genaugenommen nur wirklich richtig Sinn wenn ich auch exec verbiete, jetzt muss ich schauen wie ich am besten eine vhost-eigene php.ini einbinde.
Wohlgemerkt, ich bin auf dem Server alleine und habe keine "Kunden", ich möchte aber lernen was zu tun wäre wenn zB ein Freund seine Seite auf meinem Server ablegt ohne ständig seine Software (Wordpress) auf Sicherheitslücken zu prüfen...
 
Aber ich habe auch viel gelernt! DANKE!
Click to expand...
Dafür ist ein Forum schliesslich da :D

Ist das folgende die Liste wo in der 3. Spalte dann PERDIR stehen muss, also genaugenommen PHP_INI_PERDIR
Click to expand...
Genau. Allerdings ist die Liste nicht vollständig da sie nur auf php.net beschriebene Extensions umfasst - Suhosin bleibt bspw aussen vor. Bei solchen Extensions musst du dann Google oder die Herstellerseite bemühen.

Kann auch eine "vhost-php.ini" den globalen Wert auch nicht überschreiben?
Click to expand...
Ich bin mir nicht sicher dass ich verstehe was du meinst. Bei mod_php verwendet man nur eine einzige globale php.ini, alle weiteren Einstellungen müssen uber php_value oder php_admin_value Befehle in den vHosts gesetzt werden. Dies stellt aber nicht unbedingt einen Performance-Nachteil dar, ist nur etwas ungewohnt verglichen mit den anderen Lösungen.

Für einige Werte benötige ich wohl eine vhost spezielle php.ini, zB für exec.
Click to expand...
Nicht eine php.ini (bitte nicht die Datei mit den Parameter verwechseln!) sondern ein php_admin_value disable_functions ....

Denn open_basedir macht ja genaugenommen nur wirklich richtig Sinn wenn ich auch exec verbiete[/quote]
Ja, die Restriktion gilt ausschliesslich für PHP selbst. Oft halten sich sogar PHP-Erweiterungen nicht mal daran, wie bspw. curl's FOLLOW_LOCATION aus technischen Gründen (ist wie oben gesagt bei open_basedir deaktiviert)
Falls du exec verwenden willst oder bspw noch mod_perl, ... aktivieren willst solltest du dir über Chroot (empfohlen via mod_security Erweiterung) Gedanken machen. Ist ebenfalls leicht auf zu setzen und garantiert dass der ganze Apache-Prozess inkl. Modulen nicht ausbrechen könnte sobald ITK gegriffen hat.

ich möchte aber lernen was zu tun wäre wenn zB ein Freund seine Seite auf meinem Server ablegt ohne ständig seine Software (Wordpress) auf Sicherheitslücken zu prüfen..
Click to expand...
Generell ist es auch so eine gute Idee die Limitierung zu setzen. Es kostet nur wenig zusätzlichen Administrationsaufwand, der Overhead ist sehr niedrig und bei Kompromittierung einzelner Seiten über Exploits ist nicht direkt dein ganzer Server potentiell gefährdet. Eine Applikation sollte _immer_ nur genau so viele Rechte haben wie sie braucht, das beinhaltet auch Rechte für Dateisystem-Zugriffe.
 
You must log in or register to reply here.
Back
Top