Benutzer-Werkzeuge

Webseiten-Werkzeuge


Seitenleiste

Was fehlt?

Es liegt in der Natur der Sache: Ein Wiki ist niemals fertig. Wir geben uns große Mühe, mit der Entwicklung Schritt zu halten; lassen Supportanfragen direkt in neue Artikel einfließen … aber auch wir sind nicht perfekt. Wenn du hier nicht fündig wirst: Nicht schmollen - Bescheid sagen! Unter hallo@uberspace.de steht dir unser Team gerne bereit. Hand drauf!

webserver:cgi

CGI

CGI ist die Abkürzung für Common Gateway Interface und beschreibt einen Standard, mit dem sich Webinhalte dynamisch generieren lassen.

Es ist wichtig zu verstehen, dass CGI keine Programmiersprache ist, sondern CGI-Scripts in vielen verschiedenen Programmiersprachen entwickelt werden können. Der CGI-Standard definiert vielmehr, wie ein Webserver mit einem CGI-Script kommunizieren kann: So wird festgelegt, welche Umgebungsvariablen der Webserver dem Script bereitstellt (diese enthalten dann Informationen über den HTTP-Request und ggf. übermittelte Formularparameter) sowie auch das Format der Antwort (mindestens ein Content-type-Header, Leerzeile, dann die eigentliche Antwort). Das war's dann im Großen und Ganzen auch schon.

CGI-Scripts eignen sich für allem für schnelle, kleine Lösungen ohne große Ansprüche. Der große Nachteil bei CGI ist nämlich, dass bei jedem Aufruf der entsprechend dazu führenden URL das Script komplett neu gestartet wird, also zunächst der Interpreter der jeweiligen Programmiersprache, der dann das Script einliest und ausführt. Für komplexe Vorhaben ist CGI daher eher weniger geeeignet; hier solltest du eher mal einen Blick auf FastCGI werfen, was ein entsprechendes Script persistent betreiben kann. Aber hier soll es ja nun erstmal um CGI gehen.

Scripts in cgi-bin

Bei Uberspace.de stellen wir dir standardmäßig ein cgi-bin-Verzeichnis bereit, in dem du deine CGI-Scripts ablegen kannst. Wichtig ist, dass die Scripts ausführbar sind - dazu solltest du die Rechte 0755 (Lese- und Ausführungsrechte für alle, Schreibrechte nur für dich) vergeben. Vergibst du weitergehende Schreibrechte, werden die Scripts aus Sicherheitsgründen nicht mehr ausgeführt; vergibst du weniger Rechte, kann der Webserver das Script möglicherweise nicht lesen und ausführen.

Wir setzen bei der Ausführung von CGI-Scripts suEXEC ein, das dafür sorgt, dass das Script nicht mit den Rechten des Webservers, sondern mit deinen Rechten gestartet wird. Es kann also genau die Dateien lesen und schreiben, die du auch auf der SSH-Shell lesen und schreiben kannst.

Scripts außerhalb von cgi-bin

Es ist technisch auch möglich, CGI-Scripts außerhalb des cgi-bin-Verzeichnisses auszuführen, also innerhalb deines DocumentRoots. Das musst du allerdings zunächst ausdrücklich erlauben, und zwar mittels einer .htaccess-Datei mit diesem Inhalt:

Options +ExecCGI
AddHandler cgi-script .cgi

Anschließend werden alle Dateien mit der Endung .cgi als CGI-Script ausgeführt, auch außerhalb von cgi-bin. Wichtig ist, dass die Scripts ausführbar sind - dazu solltest du die Rechte 0755 (Lese- und Ausführungsrechte für alle, Schreibrechte nur für dich) vergeben. Vergibst du weitergehende Schreibrechte, werden die Scripts aus Sicherheitsgründen nicht mehr ausgeführt; vergibst du weniger Rechte, kann der Webserver das Script möglicherweise nicht lesen und ausführen. Dies gilt nicht nur für das Script selbst, sondern auch für das Verzeichnis, in dem es liegt - setz also auch bitte für jenes mit einem chmod 755 die entsprechenden Rechte.

Wir auch bei der Ausführung via cgi-bin kommt auch hier suEXEC zum Tragen, das dafür sorgt, dass das Script nicht mit den Rechten des Webservers, sondern mit deinen Rechten gestartet wird. Es kann also genau die Dateien lesen und schreiben, die du auch auf der SSH-Shell lesen und schreiben kannst.

Welchen Sinn hat dann noch ein separates cgi-bin-Verzeichnis? Einer der Gründe ist, dass es damit schwerer wird, versehentlich den Code eines Scripts (der ja potentiell sensible Daten beinhalten kann oder aus anderen Gründen nicht öffentlich sein sollte) öffentlich zu machen. Viele Texteditoren wie vi oder nano legen beispielsweise Sicherungskopien von Dateien während der Arbeit an, oder bei einem erzwungenen Schließen des Editors (z. B. weil deine Internetverbindung abbricht, während du gerade mit dem Editor arbeitest). Der nano-Editor beispielsweise würde beim Bearbeiten einer script.cgi-Datei bei einem solchen Abbruch eine script.cgi.save hinterlassen. Liegt diese nun innerhalb des DocumentRoots und jemand ruft die URL …/script.cgi.save auf (einfach aufs Geratewohl!), so wird das Script nicht etwa ausgeführt, sondern angezeigt - der Server „erkennt“ CGI-Scripts in diesem Fall ja nur an der Endung, und die lautet hier .save und nicht .cgi. Der Aufrufende würde also deinen Programmcode einsehen können, was du möglicherweise nicht möchtest. Läge jene script.cgi.save jedoch im cgi-bin-Verzeichnis, so würde sie beim Abruf dennoch ausgeführt, weil die Vorgabe von cgi-bin ist, dass alles, was darin liegt, als Script ausgeführt wird.

Weitergehende Informationen

Eine gute Einführung in CGI-Scripts findest du beispielsweise in der Dokumentation des Apache-Webservers. Auch das Standardwerk SELFHTML hat einen Abschnitt über CGI-Scripts. Beide können nur eine erste Anlaufstelle sein. Für tiefergehende Dokumentation solltest du in jedem Fall die CGI-spezifische Dokumentation der von dir gewählten Programmiersprache konsultieren.

webserver/cgi.txt · Zuletzt geändert: 2015/11/29 07:41 von uber