Python-Shell und Portscan beim Webhoster

[droptix]

Du sagst, das PHP mit den Webserver-Account läuft. Und Python??? Python CGI Skripte sollten eigentlich auch mit den Rechten der Webservers laufen.

Python verarbeitet der Webserver nicht, also kann keine Python-Skripte als URL aufrufen. Aber ein Cronjob startet Befehle auf dem Betriebssystem (nicht dem Webserver). Cronjobs kann ich jede Minute starten. Daher habe ich eine Datei "cronjob.py" in meinem Speicher liegen, die jede Minute aufgerufen wird. Wenn ich die nun jede Minute bearbeite und einen neuen Befehl reinschreibe, habe ich eine 1-Minute-Shell Also rein technisch kann ich alles machen, nur eben seeehr langsam und aufwändig.

Warum schaufelst du die Archiv Datei nicht direkt per Upload hoch? Ein Skript auf dem Server könnte es theoretisch entpacken und per FTP speichern. Ist zwar auch sehr umständlich, aber dann hast du keine Probleme mit den Dateirechten.

Mach ich ja: ich schaufel beispielsweise das tar.gz-Archiv hoch und starte dann als Cronjob den tar-Befehl zum entpacken. Anschließend lösche ich das tar.gz-Archiv und leere den Cronjob.

[jens]

In dem Falle würde ich mal den Hoster wechseln

[droptix]

Was wie bereits gesagt für mich keinen Sinn macht.

1) Hab ich bei preislich vergleichbaren Anbietern keine Symlinks.
2) Nützt mir Python über CGI auch nichts, wenn die Skripte nicht unter meinem Account ausgeführt werden.

[jens]

Shell, Symlinks und fastCGI habe ich bei GPcom schon. Allerdings hast du recht, die Skripte werden mit den Rechten vom WebServer ausgeführt. Das ist IMHO bei allen Shared-Webhostern leider so

Ansonsten wäre das PyHosting Projekt was für sich: ##pyhosting @ irc.freenode.net Aber eigentlich ist der Server dort dicht.

[droptix]

Tja für CGI gibt's ja mod_suexec, um die unter Benutzerrechten auszuführen. Speziell für PHP gibt's suPHP.

Leider benutzt das kaum ein Webhoster. Zumindest kenne ich keinen. Die Webserver sollen angeblich ein wenig an Performance einbüßen, wenn man diese sinnvollen Möglichkeiten einsetzen würde.

[jens]

Ich würde nicht sagen das es an der Performance scheitert. Ansonsten würde kein WebHoster CGI anbieten, sondern nur fastCGI und Co.

Vielmehr wird es wohl der Mehraufwand sein. Python als CGI mit Apache ist ja quasi mit jeder Linux-Distro per default vorkonfiguriert. Alles andere nicht.

Warum Hoster diesen Mehraufwand nicht auf sich nehmen, liegt wohl einfach an der geringen Nachfrage. Das wiederum liegt IMHO nicht unbedingt daran, das Python im Web nicht eingesetzt wird. Viel mehr nutzten Python Leute ehr einen eigenen Server und kein Shared-Webhoster. Ganz anders wie es wohl bei PHP ist

[Leonidas]

Ansonsten wäre das PyHosting Projekt was für sich: ##pyhosting @ irc.freenode.net Aber eigentlich ist der Server dort dicht.

Dort ging es eher um hochqualitative Xen-Instanzen und die kosten wohl ähnlich wie "herkömliche" Virtuelle Server.

[birkenfeld]

Es gibt auch VServer ab 5,- EUR, aber billig ist echt nicht immer gleich gut. 10,- EUR/Monat reize ich nicht aus, weil mir da auch zuviel dabei ist. Ich bin derzeit bei 2,50 EUR

Auch für 3,00 EUR bekommst du einen vServer, und nicht mal einen schlechten...

[jens]

PyHosting Projekt

Dort ging es eher um hochqualitative Xen-Instanzen

Nicht nur. Dort gibt es einen Shared-WebHosting bereich! Da bin ich als User mit dabei.
Hat den Vorteil, das man wesentlich mehr Freiheiten hat, als bei einem normalen Hoster. Beispielsweise hat jeder User seine eigene apache-conf.