nicht angemeldet
Hi Christoph,
Na, dann kannst Du auch ein kleines CGI-Skript schreiben, welches nichts anderes tut, als den (wahrscheinlich) make-Aufruf für die Übersetzung von ImageMagick auszuführen.
Sollte das funktionieren, ist der Provider unverzüglich zu wechseln.
Ich kann mir nicht vorstellen, daß das nicht funktionieren sollte.
Um das klarzustellen: Ich meint natürlich nicht, das Programm in ein _Systemverzeichnis_ installieren zu können.
Aber das Zielverzeichnis steht ja in diesem Fall im Makefile drin.
Also kann ich
1. das Makefile editieren und per FTP hochladen und
2. ein CGI-Skript schreiben, welches das Programm in ein Verzeichnis innerhalb _meines_ Webspace installiert.
Ich muß es dann wahrscheinlich über den vollständigen Pfadnamen aufrufen, falls ich nicht sogar $PATH entsprechend setzen kann - aber ich würde mich sehr wundern, wenn mir ein Provider _das_ irgendwie unterbinden, aber gleichzeitig normale eigene CGI-Skripte erlauben würde.
(Notfalls kann ich mir sogar ein eigenes "make" per FTP hochladen und per CGI-Skript ausführbar machen ...)
Der Provider kann seine Maschine ggf. so konfigurieren, daß die Default-Shell 'sh' nicht viel kann (restricted shell etc.). Aber damit macht er so viele Freeware-CGI-Skripts kaputt (die beispielsweise "sendmail" aufrufen statt ein gleichwertiges Perl-Modul), daß er es besser bleiben lassen sollte.
Wenn man den Benutzern CGI erlaubt, dann bleibt außer Benutzerkennungen nicht mehr arg viel übrig zur Absicherung. Das muß aber auch reichen!
UNIX-Benutzerkennungen sind für den parallelen, abgeschotteten Betrieb getrennter shell-Benutzer gedacht - und ein CGI-Skript ist nichts wesentlich Anderes als eben eine solche Shell. (Weshalb ein solcher Provider ohne "cgiwrapper" wahrscheinlich auch nicht glücklich werden wird.)
Wer schon derartige Lücken in der Eigensicherung aufweist, bei dem ist anzunehmen, das auch noch verschiedene andere bestehen, die zu durchaus peinlichen Vorfällen führen könnten.
Ich glaube nicht, daß der Provider eine realistische Chance (oder auch nur ein Interesse!) hat, das zu verhindern.
Was geht es ihn auch an, ob mein CGI-Skript in Perl ein anderes Perl-Modul oder ein semantisch gleichwertiges C-Programm aufruft?
Die Frage ist doch eher, welche Privilegien meine Benutzerkennung hat, d. h. ob sie auf /usr/bin lesend zugreifen darf etc. Dafür gibt es Konzepte wie chroot und Benutzerkennungen/Gruppen; nichts davon stört mich aber dabei, in meinem _eigenen_ Webspace Programme zu übersetzen und zu installieren. Solange sich die UNIX-Kiste wie eine UNIX-Kiste anfühlt, kann ich mich darauf wie auf einer UNIX-Kiste bewegen.
Siehe auch die doch arg auf Sicherheit bedachten Leute von Sourceforge.net, die letztes Jahr dann doch die Compiler vom Shellserver ganz entfernen mußten.
Davon weiß ich nichts. Hatten die Compiler selbst irgendwelche Sicherheitslücken und waren privilegiert installiert? Ansonsten würde ich es nicht verstehen.
An anderer Stelle im aktuellen Forum sind mehrere CGI-Skripte beschrieben, welche Dir eine abgemagerte Variante von telnet zur Verfügung stellen würden.
Auch ein telnet ist ein Zeichen mangelnden Sicherheitsbewussteins. SSH ist hier die erste Wahl. Das wäre mal eine Idee für Perlprogrammierer ;-)
Genau wie oben geht es mir nicht darum, per CGI das telnet-_Protokoll_ nachzubilden (wozu auch?), sondern die telnet-_Semantik_ (nämlich eine Dialog-Shell). Und die ist identisch zur SSH-Semantik - als Benutzer interessiert mich doch gar nicht, wie die Kommandos übertragen werden, sondern lediglich, welche Kommandos ich zur Verfügung habe.
Ein solches Skript ist zwar unsicherer als ssh (immerhin kann man kaum Passworte belauschen, weil es sich mangels "su" gar nicht lohnt, welche einzugeben), aber es ist nicht zu verhindern, ein solches Skript zu betreiben, wenn ich eigene CGI-Skripte installieren darf - es _ist_ nämlich ein eigenes CGI-Skript und nichts anderes.
Es ist sogar ziemlich exakt so sicher wie telnet, wenn ich es per server authentification && "AuthType Basic" zugangsschütze (es völlig offen herum stehen zu lassen wäre natürlich in der Tat schrecklicher Leichtsinn - aber nicht vom Provider, sondern von mir,weil ein Besucher dann genau _meine_ Daten zernichten kann, sonst aber keine.)
Insofern finde ich es ziemlichen Unfug, wenn ein Provider einem Benutzer eigene CGI-Skripte erlaubt und SSH nicht. Das Einzige, was er damit bewirkt, ist, daß sich der Benutzer eine weniger sichere 'SSH-Emulation' als CGI-Skript installieren muß ...
BTW: auf gut administrierten Servern läuft normalerweise erst gar kein telnetd mehr. Das sagt doch schon viel, oder? ;-)
Wahr, aber irrelevant (siehe vorheriger Absatz). Es geht nicht um das verwendete Protokoll.
Und HTTP kann der Provider ja schlecht verbieten, wenn er CGI-Skripte erlaubt - nicht wahr? ;-)
Viele Grüße
Michael