Zu Perl und UserInnen auf einem Apache-Server gibt es wohl schlichtweg keine machbare Lösung. Oder doch?
Aufgabe
Die Aufgabe ist folgende: Auf dem Apache-Server unter Perl die Programme und Skripte mehrerer UserInnen unabhängig und sicher zu betreiben. (K)ein problem? Nun, im Prinzip Ja, sprach Radio Eriwan.
Lösungswege
Natürlich werden einige sagen: Es ist es schon möglich, Perl laufen zu lassen ohne das Problem zu haben, dass UserInnen auf andere Verzeichnisse zugreifen oder sonstwas böses können.
Sicher, es ist möglich. Wie möchte ich hier trotzdem erläutern, auch wenn einige Linuxerfahrene es schon wissen sollten.
Weitere Lösungen wären, bestimmte Apache-Module und/oder Wrapper zu verwenden. Davon gibt es einige.
Dateirechte einschränken
Die Dateiverwaltung von Linux lässt eine Restriktion auf bestimmte Verzeichnisse zu, wenn UserInnen bestimmten Gruppen zugeordnet werden und Verzeichnisse nur auf diese UserInnen einzeln oder Gruppen beschränkt werden. Das geschieht über die Dateizugriffsrechte mit chmod sowie die Besitzrechte mit chgrp und chown.
Diese Festlegung wird sowieso gemacht, wenn neue UserInnen für das Linux bzw. den Server angelegt werden. Home- und Web-/Intranet-Verzeichnisse werden dann nur für den Zugriff der UserInnen bzw. der Arbeitsgruppe zugelassen.
Jailing
Beim Jailing werden die Skripte mittels Wrappern so in ihren Möglichkeiten beschnitten, dass sie nur mit bestimmten Prozessrechten laufen und nur auf bestimmte Verzeichnisse zugreifen dürfen.
Ein Programm, was dies macht, ist zum Beispiel suexec oder CGIWrap.
Apache-Module
Es gibt mehrere Module für Apache, um Skripten die Freiheit zu beschränken. In Zusammenhang mit suexec gibt es das Modul mod_suexec. Außerdem diverse andere, die auf dem Multiprocessing-Modul (MPM) aufbauen.
Nähere Betrachtung
suexec
suexec ist fein. Kein Problem, denn dort lassen sich per UserID und UserGroup (unter Linux) Rechte für die Verzeichnisse und Skripte zuweisen. Unter Apache findet das Modul mod_suexec Verwendung.
suexec ist zwar für Umgebungen, bei denen sich mehrere Nutzer einen Srver teilen, gut konfigurierbar, aber eben langsam, da jedesmal der Perl-Interpreter starten muss, wenn ein Skript läuft.
Für performante Systeme also nur bedingt nutzbar.
mod_perl
mod_perl ist eine feine, schnelle Angelegeheit für Perl-Skripte; aber wenn es um die Sicherheit geht, mit mod_perl wird es da haarig, aders will ich es nicht nennen. Denn unter mod_perl starten alle Prozesse als Apache-Prozess (manchmal mit Rechten wie root:root, meist aber apache:apache), genauer: als Kinder desselben. Damit können natürlich die Skripte der User auf andere Dateiverzeichnisse zugreifen, auf die auch der Apache zugreifen kann. Für die Webmistress und Admina in Bezug auf Datensicherheit und -schutz eine gruselige Angelegenheit.
Nun dachte ich etws naiv, es muss doch auch so etwas in mod_perl wie open_basedir in PHPs safemode (keine Diskussion, dass auch dies unsicher sein kann) geben. Weit gefehlt! Nichts in mod_perls Dokumentation und auf perl.apache.org auch nicht. Selbst das Graben im Forum der Perl-Community und das Anwerfen diverser Suchmaschinen ließ mich im Regen stehen.
Also dachte ich mir, ich poste dort mal eine Anfrage, wie andere das Handhaben, ob es nicht doch irgendwelche Apache-Module geben müsste, die weiter helfen.
Es gibt einige Apache-Module, die zur Userverwaltung taugen. Als da wären: MPM perchild, Metux MPM, Peruser MPM und MPM ITK.
perchild
mpm_perchild ist ein interessantes Modul. Es erlaubt bestimmten Apache-Prozessen UserIDs und -Groups zuzuordnen. Damit wäre es ja machbar.
Doch leider bringt der kritische Blick (auch RTFM gedacht und gemacht) in das Manual folgendes zutage:
This module is not functional. Development of this module is not complete and is not currently active. Do not use perchild unless you are a programmer willing to help fix it.
Also nichts – ein eingeschlafenes Modul.
Metux MPM
Nicht mehr mit einer Entwicklerseite auffindbar im WWW. Der erguhgelte Links ist ein Wiki gefüllt mit SPAM.
Wieder nichts.
peruser MPM
peruser-mpm lässt sowohl ein chroot (also Jailing) als auch eine Userverwaltung nach ID und Group für die Kindprozesse des Apache zu.
Allerdings ist es so, dass das Mdoul auch immer noch experimentell und laut Entwickler nichts für Produktivsysteme ist. Zudem kommt es nur bedingt mit SSL und mod_ssl klar.
Also wieder nichts.
MPM ITK
MPM ITK ist also der nächste Kandidat. Auch diese kann dieses und jenes.
Aber dann wieder der Hinweis: Note that mpm-itk is experimental software
schreibt der Entwickler. Pustekuchen, nichts zum vwrwenden.
Zu gibt es ein paar Artikel im Netz wie von Mitka oder aus dem PHP-Magazin und Stuart Herberts Artikel The Challenge With Securing Shared Hosting
.
Dass Shared Hosting eine Herausforderung ist, wenn es um Performance und Sicherheit geht, ist ein alter Hut, mottenzerfressen und ab und an nicht reparierbar.
Also kurz gesagt: Bei mpm-itk muss der ganze Apache neu kompiliert werden muss. Für Zuhause machbar, in der Firma gerade noch (bis irgendwann nichts mehr geht). Aber in der Wildnis
draußen, im WWW, bei Kunden? Auf einem externen Server? Nein.
Also wiederum schlecht für einen Produktivserver brauchbar.
Server als VM
Sicherlich ist es möglich, pro UserIn einen komplett virtuellen Server mittels VM laufen zu lassen. Eine VM kapselt ja jedes System völlig ab.
Aber sowas geht nicht immer, erfordert ziemliche Resourcen. Server sollen ja zügig laufen, nicht zimperlich.
Und eine VM als Server laufen zu lassen ist auch gerade nicht die Aufgabe.
Fazit
Es gibt viele Möglichkeiten, die aber näher angesehen einfach unfertig sind. Keine schöne Sache für Perl unter dem Apachen.
Mit mod_perl ist da wohl derzeit nichts machbar. Nur will ich kein PHP haben udn auch nicht weiter empfehlen müssen.
mod_perl ist sehr schön, aber warum hinkt es da so nach, was Multiuserumgebungen auf Servern anbelangt? Der Weiterverbreitung von mod_perl ist das nicht förderlich.
PS: Die Leiden der Webadmina wäre ein weiteres Thema im Blog, denke ich ab und an.

Kommentar für Blogeintrag
Vorschau des Kommentars
TrackBack-URL:
http://gwendragon.de/blog/Web/Server/perl-multiuser-faehig.html/trackback↑Artikel