WCM Forum - cgi mit c/c++

WCM Forum (http://www.wcm.at/forum/index.php)

- Programmierung (http://www.wcm.at/forum/forumdisplay.php?f=17)

- - cgi mit c/c++ (http://www.wcm.at/forum/showthread.php?t=29156)

Zitat:

Jeder vernünftige Dienstleister darf bei den Kundenscripten keine Auswahl treffen. Das währe ja selbstmord, Kunde bezahlt für den Account und der Provider schmeißt die Scripten wieder runter, wenn sie ihm nicht gefallen.

Bei mod_perl schon :). Keiner der grossen Provider bietet es an ausser natürlich auf dedizierten Servern. Provider die es doch anbieten werden auf Boards wie www.webhostingtalk.com meistens verrissen. Dabei handelt es sich meistens um kleine 1 Mann Provider die mit wenig Erfahrung einen Server z.b. um $99 Mieten und dann ihren Kunden tolle Features wie mod_perl bieten.

Übrigens bei vielen Servern ist mod_perl zwar installiert wird aber nicht verwendet z.b. bei Cobalt RaQ Servern. Das normale Verzeichnis für mod_perl Scripte ist perl-bin

Zitat:

Das kommt nur bei Wohnzimmerprovider vor, die einen schwachen Rechner haben, und keiner eine Serverlast erzeugen darf. Sonst geht der Compi mit 128 Ram gleich in die Knie
Ausserdem ist es egal was die Kunden raufladen, du kannst mit Apachemodule die Prozessorzeit und den Ramverbrauch steuern, so kann keiner den Server mit einem Prozess abschießen.

Ich würde Tera-Byte nicht unbedingt bei 1 Mio Kunden und 22000 TB/Transfer als Wohnzimmerprovider bezeichnen. Das gleiche gilt für Ventures Online die vor 2 Monaten YaBB/UBB von ihren Servern gebannt haben.

Zitat:

2, Für das gibt es Suexec: Das steuert den Zugriff auf Scripten und ist gnadenlos beim Überwachen und ausführen (siehe meinen Thread über Suexec)

Vielleicht hilft das bei den Resourcen aber was ist mit den Root Privilegen von mod_perl? Da es nicht als CGI läuft und daher nicht an User und deren Verzeichnisse gebunden ist öffnet es eigentlich ein relativ grosses Sicherheitsloch.

Zitat:

3, Hä, 2 Apachen am selben Port

Ich kann ja dann nachschauen aber soviel ich mich erinnern kann werden alle Scripte im /perl-bin Verzeichnis am zweiten Server ausgeführt :)

mod_perl ist, wenn der Apache mit Suexec übersetzt wurde, an den User und die Gruppe gebunden.
Mußte leider diese Erfahrung erst vor kurzem machen.

Also laut mehreren Fachbüchern (zb.Lars Eilebrecht, der Apache Webserver) besteht null Risiko, wenn man Suexec dazu einsetzt.
Ganz im Gegenteil, bei mir wollte es durch Suexec überhaupt nicht laufen, da das Script von mehreren Accounts (Unterschiedliche UID) genutzt werden sollte.

Mußte mich ein wenig mit den Programmierern von ("Kaffee&Kuchen", http://java.seite.net), Javascript ("Kakao&Kekse", http://javascript.seite.net) und Dynamic HTML ("Milch&Zucker", http://dhtml.seite.net)
herumschlagen, da die auf mod_perl schwören, und wir gemeinsam für eine dritte Firma Dienstleistungen erbrachten.
Auf den Server laufen mehrere Accounts, Sicherheit wird da mächtig groß geschrieben (gehört einer Bank).

Fazit: Apache-Suexec-mod_perl= Script wird wesentlich schneller abgearbeitet, und eine externe Agentur konnte keine Sicherheitsrisiken finden.

Nocheinmal, nur in Verbindung mit Suexec, ohne dem Wachhund können Aussenstehende auch mit mod_cgi machen was sie wollen (Scripte aufrufen ohne Berechtigung).

Kleine Auswahl von Provider die mod_perl einsetzen, sind auch große Amis dabei ;)

http://perl.apache.org/isp.html

http://perl.apache.org/

Sloter

Jetzt habe ich auf Webhostingtalk nachgesehen. Laut Matt Freeman (einen Moderator dort) funktioniert SuExec nicht mit mod_perl und mod_php:

Zitat:

There are one or two disadvantages to using SuExec. All php, perl and other scripts have to be executed in CGI mode, meaning you can't use mod_php and mod_perl since these run in-process and don't support username switching, hence creating an extra burden on server resources.

http://www.webhostingtalk.com/showth...threadid=11391

Vergewissere dich daher ob die Scripte wirklich unter mod_perl laufen und wenn ja dann poste die Einstellungen auf WHT da es sicher viele interessieren würde.

Hier ein kleiner mod_perl tester:

Code:

#!usr/bin/perl -w

use strict; 



print "Content-type: text/html\n\n";



if ($ENV{'MOD_PERL'}) {

    print "Mod_perl is installed on this server: $ENV{'MOD_PERL'}



\n";

} else {

    print "Mod_perl is not installed on this server



\n";

}

Zitat:

Kleine Auswahl von Provider die mod_perl einsetzen, sind auch große Amis dabei

Die Liste kenne ich schon :). Dort bieten die Provider es entweder nur wenn man einen eigenen Server nimmt bzw. wenn das Script vorher vom Provider angeschaut und genehmigt wird. Einzig HostPro scheint konseqent zu sein und bietet ihren Kunden auf den Freedom 400x/500x vollen Root Zugang :eek: und daher wahrscheinlich auch mod_perl auf diesen Accounts.

Ich glaube da könnten wir stundenlang Diskutieren.

Ich gebe mich geschlagen :)

Im Grunde kann man viel hacken, sicher ist leider kein System :(

Sloter