dateien auf webserver überschreiben

[FraFu]

Hallo!

Folgendes Szenario:
Ich spiele auf eine Webseite Dateien (php) mit einem FTP Client rauf. Die Dateien haben als Besitzer/Gruppe den User des eingeloggten FTP Accounts.

Wenn ich diese PHP Dateien mit dem Webbrowser aufrufe, werden diese Dateien mit dem User ausgeführt, mit dem der Webserver läuft.

Soweit richtig?

Ich habe jetzt eine php Datei (rename.php) die folgenden Code enthält:

  
copy("a.php", "b.php");  

Sowohl rename.php als auch a.php und b.php wurden per FTP Client übertragen (Dateien habe die Attribute 644).
Im "Normalfall" müsste das Copy eine Fehlermeldung produzieren, da ja der PHP Prozess nicht die Rechte haben dürfte, diese Dateien zu verändern.

Zu meiner Überraschung, geht das bei meinem Provider allerdings.

Ich hab eigentlich erwartet, dass das erst geht, wenn ich die Attribute von b.php auf 664 oder 666 ändere.

Was meinen die Spezialisten in diesem Forum? Würdet ihr das bei meinem Provider als eine Fehleinstellung werten?

Ich kann nicht davon ausgehen, dass der Code (copy('a.php', 'b.php')) so ohne weiteres bei jedem Webhoster funktioniert, oder?

mfg
  frafu

[Cheatah]

Hi,

Wenn ich diese PHP Dateien mit dem Webbrowser aufrufe, werden diese Dateien mit dem User ausgeführt, mit dem der Webserver läuft.

Soweit richtig?

jein: mit dem User, unter dem die Webserver-Children laufen. Der Server selbst dürfte i.d.R. als root agieren.

Im "Normalfall" müsste das Copy eine Fehlermeldung produzieren, da ja der PHP Prozess nicht die Rechte haben dürfte, diese Dateien zu verändern.

Wie lauten die User/Gruppen des FTP-Accounts und der Server-Children?

Ich hab eigentlich erwartet, dass das erst geht, wenn ich die Attribute von b.php auf 664 oder 666 ändere.

Ist es überhaupt ein Unix/Linux? ;-)

Was meinen die Spezialisten in diesem Forum? Würdet ihr das bei meinem Provider als eine Fehleinstellung werten?

_Kann_ sein, muss aber nicht. Vorerst bin ich ebenso verwundert wie Du, ich möchte aber erst o.g. Fragen geklärt haben.

Cheatah

[FraFu]

Hallo!

Wie lauten die User/Gruppen des FTP-Accounts und der Server-Children?

Wenn ich Dateien mit FTP übertrage haben die Dateien folgende User/Gruppen Attribute:
f192/frafu9

Wie finde ich die User/Gruppe der Server Children raus?
Ich versuchs mal auf diese Art:
Wenn ich mit php ein File erzeuge (fopen und fputs), kann ich das ohne das ich die Verzeichnisattribute ändern muss.
Die so neu erzeugte Datei hat ebenfalls f192/frafu9 als Besitzer. Das ist doch der User/Gruppe des PHP Prozesses?
Das erklärt, warum ich so einfach mit php Dateien überschreiben kann.

Ich hab eigentlich erwartet, dass das erst geht, wenn ich die Attribute von b.php auf 664 oder 666 ändere.

Ist es überhaupt ein Unix/Linux? ;-)

Definitiv.

Was meinen die Spezialisten in diesem Forum? Würdet ihr das bei meinem Provider als eine Fehleinstellung werten?

_Kann_ sein, muss aber nicht. Vorerst bin ich ebenso verwundert wie Du, ich möchte aber erst o.g. Fragen geklärt haben.

Was bedeuten meine Beobachtungen jetzt? :-) Einfach "komisch" konfiguriert oder auch ein pot. Sicherheitsrisiko?

mfg
  frafu

[wahsaga]

hi,

Was bedeuten meine Beobachtungen jetzt? :-)

Vielleicht ist das System so eingerichtet, dass dein FTP-Benutzeraccount einfach mit dem Nutzer, unter dem PHP läuft, identisch ist?

Einfach "komisch" konfiguriert oder auch ein pot. Sicherheitsrisiko?

Nö, im Gegenteil würde ich sagen - ziemlich gut konfiguriert sogar.
FTP und PHP laufen über den gleichen User, also brauchen nur für genau diesen einen User Schreibrechte vergeben werden-  noch nicht einmal für eine User_gruppe_, geschweige denn für alle.

gruß,
wahsaga

[FraFu]

Hallo!

Nö, im Gegenteil würde ich sagen - ziemlich gut konfiguriert sogar.
FTP und PHP laufen über den gleichen User, also brauchen nur für genau diesen einen User Schreibrechte vergeben werden-  noch nicht einmal für eine User_gruppe_, geschweige denn für alle.

Alles klar. Danke!
So eine Konfiguration kommt aber eher selten vor, oder?

Ich kann nicht davon ausgehen, dass der php Prozess bei anderen Providern einfach so Dateien (über)schreiben kann?

mfg
  frafu

[Cybaer]

Hi,

Ich kann nicht davon ausgehen, dass der php Prozess bei anderen Providern einfach so Dateien (über)schreiben kann?

Kommt auf dessen Sicherheitslücken an. ;->

Gruß, Cybaer

[Cybaer]

Hi,

Vielleicht ist das System so eingerichtet, dass dein FTP-Benutzeraccount einfach mit dem Nutzer, unter dem PHP läuft, identisch ist?

Ich weiß nicht, wie es bei FraFu ist, aber das klappt auch, wenn FTP-Account und PHP unterschiedliche Nutzer haben.

Und wenn FTP und PHP den gleichen Nutzer haben, dann stellt sich das (theoretische) Problem ja gar nicht erst. :)

Gruß, Cybaer

[wahsaga]

hi,

Vielleicht ist das System so eingerichtet, dass dein FTP-Benutzeraccount einfach mit dem Nutzer, unter dem PHP läuft, identisch ist?

Ich weiß nicht, wie es bei FraFu ist, aber das klappt auch, wenn FTP-Account und PHP unterschiedliche Nutzer haben.

Dann dürften die Dateiinformationen doch aber nicht behaupten, zwei von den beiden unterschiedlichen Nutzern angelegte Dateien hätten den gleichen Eigentümer.

Wäre es evtl. denkbar, dass da nach jedem FTP-Upload noch ein CHOWN gemacht wird, um die Datei auf den PHP-User zu übertragen ...?

gruß,
wahsaga

[Tom]

Hello,

Wäre es evtl. denkbar, dass da nach jedem FTP-Upload noch ein CHOWN gemacht wird, um die Datei auf den PHP-User zu übertragen ...?

Das hat die T-Bum mal so gemacht. Ob es noch so ist, weiß ich nicht, weil ich dort keinen Account mit PHP mehr habe.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Cybaer]

Hi,

Dann dürften die Dateiinformationen doch aber nicht behaupten, zwei von den beiden unterschiedlichen Nutzern angelegte Dateien hätten den gleichen Eigentümer.

Nein, natürlich nicht.

Aber diese Bemerkung bei FraFu habe ich überlesen. =:-) (deswegen ja auch die Anmerkung, ich wüßte nicht, wie es bei FraFu aussieht - ja, ja, ich weiß, ich sollte nicht so hektisch über die Postings gehen ... :-/).

Wäre es evtl. denkbar, dass da nach jedem FTP-Upload noch ein CHOWN gemacht wird, um die Datei auf den PHP-User zu übertragen ...?

Bei *meiner* Feststellung? Nein, ist nicht möglich. 1. weiß ich's ;-), 2. der Besitzername wird mir ja jeweils angezeigt. Und da ist es eben so, daß ich eine Datei mit Besitzer "FTP-User" und rw-r--r-- vom Benutzer "PHP-User" mit unlink löschen kann (Rechte ändern kann "PHP-User", also PHP, hier, mangels Rechte, nur mit ftp_chmod, Datei beschreiben kann PHP auch nicht). Also Datei kopieren, neue Datei hat dann den Besitzer "PHP-User", alte Datei löschen, neue Datei umbennen (so daß der Dateiname wieder stimmt, fertig.

Ein Provider hatte sogar verabsäumt, die Dateipfade der anderen Shared-Host-User für mich zu sperren (jetzt mal unabhängig von PHP: Perl ging auch noch): O-Ton nach dem Hinweis: "Aber da kommen sie doch gar nicht dran!" Jo, für (abstrahiert) /www/kundeCybaer/ hatte ich Schreib- & Leserechte, für /www/kundeXYZ/ weder noch. Dummerweise war /www/kunde*/htdocs/ wieder für alle lesbar. Und da ich die Namen der Kundenverzeichnisse auslesen konnte ...

Da war, ganz bequem, "happy defacement" möglich ...

Gruß, Cybaer

[Tom]

Hello,

da sollte man sich aber mal mit den Owner- und Gruppenfunktionen von PHP oder eben sogar vom OS (wäre noch besser) übersicht über die supplemental Groups der User und nicht nur über die initial Group Gedanken machen. Sicher wird es da irgendwelche Schnittmengen geben.

Alternativ kann man die Gruppen- und Others-Rechte mal vollständig entfernen. Wenn es dann immer noch das Gleiche Verhalten ist, stimmt wirklich was nicht.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Cybaer]

Hi,

da sollte man sich aber mal mit den Owner- und Gruppenfunktionen von PHP oder eben sogar vom OS (wäre noch besser) übersicht über die supplemental Groups der User und nicht nur über die initial Group Gedanken machen. Sicher wird es da irgendwelche Schnittmengen geben.

Sicher. Allerdings: Kann das strenggenommen eine Bedeutung haben, wenn die Gruppe ohnehin keine Schreibrechte hat, sondern nur der Besitzer? Ist ja auch nicht so, daß der "PHP-User" alles machen darf, was der Besitzer darf. Aber löschen darf er zumindest ... =:-o

Das die OS' als solche nicht wirklich fehlerhaft sind, denke ich jedenfalls schon. Dateien mit User/Group ROOT lassen sich so natürlich nicht ersetzen. ;->

Gruß, Cybaer

[Tom]

Hello,

Das die OS' als solche nicht wirklich fehlerhaft sind, denke ich jedenfalls schon. Dateien mit User/Group ROOT lassen sich so natürlich nicht ersetzen. ;->

Also, ich probiere das hier jetzt auch aus. Wenn ich rausfinde, woran der Fehler liegt, gibst Du einen aus. Wenn es bei mir richtig funktioniert, auch. ;-)

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Tom]

Hello,

Also, ich probiere das hier jetzt auch aus. Wenn ich rausfinde, woran der Fehler liegt, gibst Du einen aus. Wenn es bei mir richtig funktioniert, auch. ;-)

Also, bevor ich hier jetzt einen Aufriss mache:

WER ist OWNER:GROUP des Verzeichnis, in dem sich das Ganze abspielt?

Löschen und Kopieren, bzw. überschreiben mit copy() = Löschen und Neuanlegen richten sich nach Rechten, die für das Verzeichnis festgelegt sind. Nur Änderungen _innerhalb_ der Datei richten sich nach den Rechten, die direkt am File kleben.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Cybaer]

Hi,

Löschen und Kopieren, bzw. überschreiben mit copy() = Löschen und Neuanlegen richten sich nach Rechten, die für das Verzeichnis festgelegt sind. Nur Änderungen _innerhalb_ der Datei richten sich nach den Rechten, die direkt am File kleben.

Jo, das ist es. Danke für die Aufklärung. :)

Gruß, Cybaer

[Cheatah]

Hi,

Wie finde ich die User/Gruppe der Server Children raus?

entweder über die User-Direktive in der httpd.conf, oder durch Nachschauen in Tools wie ps oder top.

Wenn ich mit php ein File erzeuge (fopen und fputs), kann ich das ohne das ich die Verzeichnisattribute ändern muss.
Die so neu erzeugte Datei hat ebenfalls f192/frafu9 als Besitzer. Das ist doch der User/Gruppe des PHP Prozesses?

_Sollte_ so sein, ja. Das ist allerdings nur ein Indizienbeweis.

Was bedeuten meine Beobachtungen jetzt? :-) Einfach "komisch" konfiguriert oder auch ein pot. Sicherheitsrisiko?

Im Idealfall gut konfiguriert. Es ist aber auch möglich, dass es sich um eine Konstellation handelt, welche über den Apache-Hauptprozess ein sudo o.ä. auf den User ausführt; also im Prinzip "mach mich root und dann f192". Das könnte dann durchaus zu einem Sicherheitsrisiko werden.

Cheatah

[Cybaer]

Hi,

Würdet ihr das bei meinem Provider als eine Fehleinstellung werten?

Ich weiß nicht, warum das so ist, aber es ist ziemlich normal.

Ich habe das Verhalten sogar in meiner eigenen Online-Editor als automatische Möglichkeit implementiert, meine ("FTP-uploaded") Dateien zu ändern, obwohl ich nicht die Rechte dafür gesetzt habe.

Ich kann nicht davon ausgehen, dass der Code (copy('a.php', 'b.php')) so ohne weiteres bei jedem Webhoster funktioniert, oder?

Mir das schon bei einigen, ganz unterschiedlichen Providern von groß bis klein, von teuer bis preiswert aufgefallen (mein Online-Editor ist halt immer installiert :))

Gruß, Cybaer

[FraFu]

Hallo!

Ich weiß nicht, warum das so ist, aber es ist ziemlich normal.

Ich habe das Verhalten sogar in meiner eigenen Online-Editor als automatische Möglichkeit implementiert, meine ("FTP-uploaded") Dateien zu ändern, obwohl ich nicht die Rechte dafür gesetzt habe.

Genau soetwas hab ich auch vor. Ich möchte mein CMS mit einer automatisches Updatefunktion erweitern. Vorgangsweise: Ein Tar File mit den neuesten Dateien wird auf den Server gespielt. Ein PHP Script entpackt diese Datei und vergleicht diese neuen Dateien mit den existierenden anhand der MD5 Checksumme. Ist diese nicht gleich, wird das File ausgetauscht. Ich hab jetzt eigentlich vorgehabt, dass ich das austauschen über FTP mache um auf der sicheren Seite zu sein. Dass das aber auch über ein einfacht copy funktioniert, ohne die Attribute ändern zu müssen, hat mich verwundert.
Ich werd es aber trotzdem mit FTP lösen. Sicher ist sicher.

mfg
  frafu

[Cybaer]

Hi,

Dass das aber auch über ein einfacht copy funktioniert, ohne die Attribute ändern zu müssen, hat mich verwundert.

Mich auch. Genauer: Mir ist es nicht bei copy aufgefallen, sondern bei unlink. D.h., mein Editor kopiert ggf. die (schreibgeschützte) Zieldatei und löscht sie(!), wenn das Kopieren erfolgreich war. Der Besitzer der Kopie ist jetzt der Nutzer von PHP - und kann somit alles machen, inkl. Setzen der gewünschten Rechte in jedweder Form.

Ich werd es aber trotzdem mit FTP lösen. Sicher ist sicher.

Das sowieso. :) Allerdings verwende ich eine eigene CHMOD-Funktion, die, sofern die eingebaute mangels Rechte nicht funktioniert, automatisch ein ftp_chmod durchführt, sofern ich in der Site-Konfiguration dies erlaubt und FTP-Zugangsdaten hinterlegt habe.

Üblicherweise verwende ich beim Editieren der Datei aber die copy/unlink-Variante. Und ich kann das auch immer verifizieren, da der Datei-Explorer meines Editors auch Besitzer- und Gruppennamen ausgibt (sofern vorhanden).

Gruß, Cybaer

[Tom]

Hello,

Wie sind die Einstellungen für das Verzeichnis, in dem sich das alles abspielt?

Für Anlegen, Löschen, durch Kopieren überschreiben sind die Rechte verantworlich, die für das Verzeichnis gesetzt sind, und nicht die des Objektes selber.

Für Lesen und Änderungen _innerhalb_ der Datei sind deren zugewiesene Einsatellungen maßgeblich.

Ich hoffe, nun kann ich in diesem Thread auch mal ein "hilfreich" kassieren *gg*

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Cybaer]

Hi,

Ich hoffe, nun kann ich in diesem Thread auch mal ein "hilfreich" kassieren *gg*

Oder zwei ... ;-)

Gruß, Cybaer