nicht angemeldet
Hallo Zusammen,
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.
Es muß Zugriff auf das System möglich sein. Aus Sicherheitsgründen sollte das bei Perl/PHP und wie sie alle heißen beim Aufruf aus dem cgi-bin abgeschaltet sein.Bei PHP Anbietern habe ich das schon öfter gesehen (ist auch IMHO fest ein- oder besser gesagt auscompilierbar), bzw schmerzhaft festgestellt ;-)
Um das klarzustellen: Ich meint natürlich nicht, das Programm in ein _Systemverzeichnis_ installieren zu können.
Ist bei UNIX ja auch nicht nötig.
Aber das Zielverzeichnis steht ja in diesem Fall im Makefile drin.
Also kann ich
- das Makefile editieren und per FTP hochladen und
- ein CGI-Skript schreiben, welches das Programm in ein Verzeichnis innerhalb _meines_ Webspace installiert.
Nach (1) sollte (2) schon nicht mehr nötig sein.
Na gut, das 'make install' zumindest ;-)
Ich muß es dann wahrscheinlich über den vollständigen Pfadnamen aufrufen, falls ich nicht sogar $PATH entsprechend setzen kann
$PATH kannst Du direkt beim Aufruf setzen:
'PATH="$PATH:/Dein/Pfad/zum/Programm" Programm'
Wichtiger ist evt das Linking (so nur bei Linux):
'LD_LIBRARY_PATH="/Dein/Pfad/zur/Programmlib" Programm'
Läßt sich beides kombinieren, muß aber alles davor stehen.
»»aber ich würde mich sehr wundern, wenn mir ein Provider _das_ irgendwie unterbinden, aber gleichzeitig normale eigene CGI-Skripte erlauben würde.
Wenn Du Dein Programm lauffähig im cgi-bin hast, kann er das nur mit hohem Aufwand und selbst dann nicht vollständig. Da hast Du durchaus Recht.
(Notfalls kann ich mir sogar ein eigenes "make" per FTP hochladen und per CGI-Skript ausführbar machen ...)
Ja, nur hast Du da das Problem, das Du evt auch noch einen Compiler, Linker, div Tools auch noch hochladen mußt _und_ so gebaut, daß sie auf der Serverarchitektur/Kernelversion/LibCversion... auch laufen!
Es geht, ja, kann aber zu einem ungeheurem Aufwand ausarten ;-)
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.
'sendmail' ist mittlerweile durch die vielen Sicherheitslücken und die schlechte Skalierbarkeit vielerorts durch 'qmail' o.ä. ersetzt worden. Dummerweise ist die Syntax nicht exakt die Gleiche. 'postfix' wird auch viel benutzt, da ist sie die gleiche.
(Nur mal notiert, falls jemand irgendwelche merkwürdigen Fehlermeldungen bekommt ;-)
Wenn man den Benutzern CGI erlaubt, dann bleibt außer Benutzerkennungen nicht mehr arg viel übrig zur Absicherung.
Es bleibt noch einiges, ist aber nur mit viel zu viel Aufwand einsetzbar. Da spielt dann wahrscheinlich der Kunde nicht mehr mit.
Obwohl der sich schon viel zu viel gefallen läßt für sein gutes Geld!
»»Das muß aber auch reichen!
Meistens reicht es auch, aber leider wirklich nur meistens :-(
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.
Das ist nur äußerlich.
Das würde jetzt aber doch zu arg in die Eingeweide gehen um in diesem Forum (zudem auch noch alles archiviert wird! Schade eigentlich, ich fand die Idee mit dem Vorschlagen sehr gut. Hat wahrscheinlich das Archiv um ca 99% entlastet, was? ;-) Platz zu haben.
(Weshalb ein solcher Provider ohne "cgiwrapper" wahrscheinlich auch nicht glücklich werden wird.)
Es gibt auch andere (bessere?) Möglichkeiten, aber ganz 'ohne' geht es auf keinen Fall! ;-)
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.
Er hat:
Einfach keinen Compiler anzubieten ist wohl die einfachste.
Wenn einer etwas braucht, muß er den Code hergeben, der wird dann (kostenpflichtig natürlich!) kompiliert und installiert.
Er kann Sorge tragen, daß die Programme im cgi-bin ausschließlich durch Interpreter gestartet werden, es wäre also nötig den Aufruf in ein Script zu verpacken, das geht aber nicht, wenn solche Befehle wie system() o.ä. einfach nicht vorhanden sind.
Aber keine Angst, so etwas ist nicht mit ein paar Klicks getan, das erfordert Fachwissen, das keiner der normalen Sysadmins besitzt. (Bei UNIX Admins ist der Grund meist der, daß sie einfach nicht dafür bezahlt werden ;-)
Was geht es ihn auch an, ob mein CGI-Skript in Perl ein anderes Perl-Modul oder ein semantisch gleichwertiges C-Programm aufruft?
In einen C-Programm kann man sehr viele Sachen machen, die in Perl gar nicht, oder nur mit sehr hohem Aufwand möglich sind. Z.B. sich mit gesteuerten Pufferüberläufen in einen anderen Speicherbereich vorzutasten, der ihn überhaupt nichts angeht.
(Diese Möglichkeit bestand in einigen Linuxkerneln (deren Nummern ich hier besser nicht nenne (sind aber bekannt(nein, ich kann kein LISP ;-))), die leider noch auf einigen Servern laufen)
Außerdem kann ich den Perlinterpreter beschränken, das C-Programm eher weniger.
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.
Sehr schön. Woher nimmst Du aber den Kompiler, so Du ihn nicht mitbringst und keine Zugriff auf das System hast?
Solange sich die UNIX-Kiste wie eine UNIX-Kiste anfühlt, kann ich mich darauf wie auf einer UNIX-Kiste bewegen.
Schön formuliert ;-)
Leider nicht ganz wahr, dafür können viel zu viele (eigentlich sogar noch zu wenige) Beschränkungen auferlegt sein.
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.
Es wurde zuviel Schabernack damit getrieben.
Die Compilefarm ist aber noch in Betrieb. Da läßt sich aber nichts linken, daß auf den Shellserven laufen würde.
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.
Sollte es aber eigentlich. Geht schließlich um Deine Daten!
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.
Habe sie mir jetzt mal genauer unter die Lupe gelegt.
Es sind schon arge Krücken, aber immer noch besser als überhaupt nichts.
Schöne Idee das Ganze!
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.)
War 'AuthType Basic' nicht einer der 'don't use it's? ;-)
Ein wenig besser kann und sollte es dann doch sein.
Insofern finde ich es ziemlichen Unfug, wenn ein Provider einem Benutzer eigene CGI-Skripte erlaubt und SSH nicht.
Da kann ich Dir nur voll und ganz beipflichten!
Warum bekomme ich für mein gutes Geld nur so einen Schrott?
Archaisches Upload per FTP, damit machen die Jungs sogar noch Werbung!
Da schütze ich meine Seiten mühsam per Passwort in PHP Scripten und beim Upload kann sie dann jeder,der möchte, lesen?
HA!
Was kostet denn den Provider so ein SSH Zugang?
Software: nix.
Installation: per RPM o.ä.: so gut wie nix, aus den Quellen: ca 1 Stunde.
Einrichtung pro User: läßt sich automatisieren, also auch so gut wie nix.
Einrichtung der Restricted Shell: ca 3 Stunden, wenn man's sorgfältig macht
Prozessorzeit: komm, haumichab ;-)
Summe der Kosten bei 1000 Usern pro User: so gut wie nix (deutlich unter 1¢)
(Ha, endlich kann ich mal den ¢ außerhalb von /. benutzen ;-)))
»»Das Einzige, was er damit bewirkt, ist, daß sich der Benutzer eine weniger sichere 'SSH-Emulation' als CGI-Skript installieren muß ...
Die zudem wahnsinnig an Prozessorzeit fressen wird.
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.
Nein, das war schon klar. Mein Beispiel war wohl schlecht gewählt oder zumindest zu mager von erklärenden Worten begleitet ;-)
Und HTTP kann der Provider ja schlecht verbieten, wenn er CGI-Skripte erlaubt - nicht wahr? ;-)
Ja, das stimmt ;-)
Die zugrunde liegende Idee der o.a. Telnetähnlichen Scripte ist wirklich interessant. Werde mich wohl bei Gelegenheit mal näher damit beschäftigen.
so short
Christoph Zurnieden