chmod auf fernem Server

[Beat]

Frage zu chmod auf fernem Server.

Das Directory sieht so aus
-chmoddir
    chmod.pl
    chmod.txt

In dem test soll Perl die Rechte zu chmod.txt setzen.
Bei meinem lokalen Windows ist das Sinnlos, chmod ist immer true
beim Fernen Server aber misslingt es, chmod in irgend einer Weise zu setzen.
Egal was für Rechte ich chmoddir gegeben habe.

Perl läuft als User nobody. Aber auch wenn ich alle Rechte einstelle (0777)
bleibt das Wirkngslos.

Kann es sein, dass hier chmod vom Provider für Perl gesperrt ist, oder habe ich etwas übersehen?

aus dem Script:

  
my $cf = 'chmod.txt';  
  
$report .= test('.','');  
$report .= chm($cf, 0777);  
$report .= test($cf,'');  
$report .= chm($cf, 0604);  
$report .= test($cf,'');  
  
# ... snipp ..  
  
sub chm{  
    my $report;  
    $_[0] or return( "Need a File or Folder!".NL );  
    $_[1] or return( "Need a Oktstring!".NL );  
    eval{ chmod( $_[1], $_[0] )  
    } or do {  
     return( $@ . NL  
        . sprintf ("FAILURE chmod %o on %s", $_[1],$_[0] ).NL);  
    };  
    $report .= sprintf("SUCCESS chmod %o on %s", $_[1],$_[0] ).NL;  
    return $report;  
}  
  
sub test{  
    my $report;  
    $_[0] or return( "Need a File or Folder!".NL );  
    $_[1] and $report .= $_[1].NL;  
    (-e $_[0]) and $report .= "exists ". $_[0].NL;  
    (-r $_[0]) and $report .= "can read ". $_[0].NL;  
    (-w $_[0]) and $report .= "can write ". $_[0].NL;  
    (-e $_[0]) and $report .= "can execute ". $_[0].NL;  
    return $report;  
}  

test() berichtet wahrheitgetreu, was ich via FTP als Rechte gesetzt habe.

mfg Beat

[Markus**]

Kann es sein, dass hier chmod vom Provider für Perl gesperrt ist, oder habe ich etwas übersehen?

Hallo Beat!
Die Problematik find' ich interessant. Ob chmod für nobody gesperrt ist, kann ich schwer beurteilen. Leider hab ich auch grade nicht die Zeit, das zu testen, evtl. heute Abend!

ggf. kannst Du einen ftp client in perl schreiben um das zu lösen?!

Gruß, Markus

[hotti]

hi,

Perl läuft als User nobody. Aber auch wenn ich alle Rechte einstelle (0777)

Wer führt denn das PerlScript aus, der Webserver oder Du auf der Konsole?

Hotti

[Beat]

Perl läuft als User nobody. Aber auch wenn ich alle Rechte einstelle (0777)
Wer führt denn das PerlScript aus, der Webserver oder Du auf der Konsole?

CGI Script.
Ergo Apache = user nobody

Ich vermute für chmod-Ausführung wird der owner, nicht groups oder world Rechte verlangt.

mfg Beat

[hotti]

hi,

Ich vermute für chmod-Ausführung wird der owner, nicht groups oder world Rechte verlangt.

Richtig. Btw., ein ordentlicher Provider hat SuExec. Das h., der Apache für http://example.com läuft unter dem gleichen Account wie der owner von DOCUMENT_ROOT /s.

Hotti

[Beat]

Ich vermute für chmod-Ausführung wird der owner, nicht groups oder world Rechte verlangt.

Richtig. Btw., ein ordentlicher Provider hat SuExec. Das h., der Apache für http://example.com läuft unter dem gleichen Account wie der owner von DOCUMENT_ROOT /s.

Das kann ich nicht beurteilen. Unter Umständen reisst du dir ganz andere Löcher auf. Installier dir doch mal Software mit Schwachstellen. Dann hast du ev. alles in DocRoot im Arsch.

mfg Beat

[CPAN]

chmod wirft keine Exception im Fehlerfall, daher macht eval hier nicht, was du denkst, was es macht. Entweder du benutzt autodie, um Exceptions zu erzeugen, oder änderst deinen Code.

  
my $file_name = 'chmod.txt';  
  
for my $mode (0777, 0604) {  
    chmod $file_name, $mode or warn "could not change mode $mode: $!\n";  
}  

[Beat]

chmod wirft keine Exception im Fehlerfall, daher macht eval hier nicht, was du denkst, was es macht. Entweder du benutzt autodie, um Exceptions zu erzeugen, oder änderst deinen Code.

my $file_name = 'chmod.txt';

for my $mode (0777, 0604) {
    chmod $file_name, $mode or warn "could not change mode $mode: $!\n";
}

  
Das hatte ich in der Version zuvor. Allerdings ändert das nichts. Mein Process ist halt nicht owner sondern nur world (user nobody).  
  
mfg Beat

-- 

><o(((°>           ><o(((°>  

   <°)))o><                     ><o(((°>o  
Der Valigator leibt diese Fische

[Struppi]

Das hatte ich in der Version zuvor. Allerdings ändert das nichts. Mein Process ist halt nicht owner sondern nur world (user nobody).

Läßt du dir den die Warnungen auch anzeigen?
z.b. mit CGI::Carp qw(warningsToBrowser);

oder so:

sub chm{  
    $_[0] or return( "Need a File or Folder!".NL );  
    $_[1] or return( "Need a Oktstring!".NL );  
    chmod( $_[1], $_[0] ) or return  sprintf("FAILURE chmod %o on %s - because: %s", $_[1],$_[0], $! );  
    return sprintf("SUCCESS chmod %o on %s", $_[1],$_[0] ).NL;  
}  
  

Struppi.

[Beat]

Das hatte ich in der Version zuvor. Allerdings ändert das nichts. Mein Process ist halt nicht owner sondern nur world (user nobody).

Läßt du dir den die Warnungen auch anzeigen?
z.b. mit CGI::Carp qw(warningsToBrowser);

Ja klar. Wird alles in ein File geleitet.
Fehlerfrei.

mfg Beat

[Struppi]

Das hatte ich in der Version zuvor. Allerdings ändert das nichts. Mein Process ist halt nicht owner sondern nur world (user nobody).

Läßt du dir den die Warnungen auch anzeigen?
z.b. mit CGI::Carp qw(warningsToBrowser);

Ja klar. Wird alles in ein File geleitet.
Fehlerfrei.

Hmm, dann läßt sich dir nicht weiterhelfen, bei mir läuft dein Skript einwandfrei.

Struppi.

[Alexander (HH)]

Moin Moin!

Kann es sein, dass hier chmod vom Provider für Perl gesperrt ist, oder habe ich etwas übersehen?

Nein. Perl hat keine so bekloppten Beschränkungsmodi wie PHP. Wenn chmod gesperrt ist, dann irgendwo unterhalb von Perl. Ich frage mich nur, warum jemand so etwas überhaupt versuchen wollen sollte. Es hat keinen Sinn, und ich kenne kein gängiges Betriebssystem, das chmod für einen stinknormalen User sperrt. (Selbst nobody ist ein normaler User, nur ohne Home-Verzeichnis, ohne Shell und ohne gültiges Passwort!)

my $report;
    $[0] or return( "Need a File or Folder!".NL );
    $[1] or return( "Need a Oktstring!".NL );
    eval{ chmod( $[1], $[0] )
    } or do {
     return( $@ . NL
        . sprintf ("FAILURE chmod %o on %s", $[1],$[0] ).NL);
    };

  
Das hier ist extrem wirr. Laß das eval weg, chmod stribt nicht gleich, wenn etwas schief läuft. do gehört hier auch nicht hin. Keine Ahnung, wo Du einen dermaßen perversen Ersatz für if-then-else gefunden hast, aber gewöhn Dir das besser gleich wieder ab. Und chmod erwartet KEINEN String für die Permissions, sondern eine Zahl, vorzugsweise in oktaler Notation.  
  
  
Die ersten drei Zeilen Deines Scripts sollten ziemlich genau so aussehen. Über den Pfad zum Perl-Executable können wir diskutieren, über den Rest nicht.  
  
~~~perl
  
#!/usr/bin/perl -T  
use strict;  
use warnings;  

So lange Du nur testest, und nicht produktiv arbeitest, kannst Du noch folgende Zeile hinzufügen. Bevor Du produktiv arbeitest, entfernst Du sie wieder.

  
use CGI::Carp qw(fatalsToBrowser);  

Und dann rufst Du chmod mal bitte ohne das ganze Theater auf, stumpf nach Handbuch:

  
my $fn='/path/to/foobar.txt';  
chmod 0600,$fn or die "Could not chmod $fn: $!";  

Von mir aus können wir für Testzwecke auch mal auf ein reines print statt die zurückstufen, das spart die Sicherheitslücke CGI::Carp:

  
chmod 0600,$fn or print "Could not chmod $fn: $!";  

Und zum Überprüfen nutzt Du bitte mal stat, ebenfalls stumpf nach Handbuch:

  
my $mode=(stat($fn))[2];  
printf "Permissions are %04o\n",$mode & 07777;  

Alexander

[Beat]

http://www.elcappuccino.ch/cgi/chmod/chmod.pl

#!/usr/bin/perl  
#  
#!perl  
  
use strict;  
use warnings;  
use constant { NL => "\n", CRLF => "\015\012"};  
BEGIN {  
	use CGI::Carp qw(carpout);  
	open(LOG, ">","error.txt")  or die "Unable to append to error.txt: $!\n";  
	carpout(*LOG);  
}  
use Cwd;  
my $cwd = getcwd();  
  
my $cf = $cwd.'/'.'chmod.txt';  
my $report;  
  
$report .= 'CWD is: '.$cwd.NL.NL;  
$report .= test($cwd,'');  
$report .= NL;  
foreach( 0777, 0606, 0404,0777 ){  
	$report .= chm($cf, 0777);  
	$report .= test($cf,'');  
}  
  
print "Content-Type: text/plain; charset=ISO-8859-1",CRLF,CRLF,  
	$report;  
exit;  
  
sub chm{  
	my $report;  
	$_[0] or return( "Need a File or Folder!".NL );  
	$_[1] or return( "Need a Octalnumber!".NL );  
	chmod( $_[1], $_[0] )  
		or return(  
			NL.sprintf("FAILURE chmod %o on %s because of %s", $_[1],$_[0], "$!" ).NL  
		);  
	$report .= sprintf("SUCCESS chmod %o on %s", $_[1],$_[0] ).NL;  
	return $report;  
}  
  
sub test{  
	my $report;  
	$_[0] or return( "Need a File or Folder!".NL );  
	$_[1] and $report .= $_[1].NL;  
	(-e $_[0]) and $report .= "exists ". $_[0].NL;  
	(-r $_[0]) and $report .= "can read ". $_[0].NL;  
	(-w $_[0]) and $report .= "can write ". $_[0].NL;  
	(-e $_[0]) and $report .= "can execute ". $_[0].NL;  
	my $mode = ( stat($_[0]) )[2];  
    $report .= sprintf( "Permissions are %04o\n",$mode & 07777 ).NL;  
	return $report;  
}  

PS keinen Bock auf -T

[Alexander (HH)]

Moin Moin!

http://www.elcappuccino.ch/cgi/chmod/chmod.pl

#!/usr/bin/perl

...

  
Was möchtest Du uns sagen?  
  
Soll jemand auf den Link klicken? OK, da steht ein paar Mal "Operation not permitted", mit anderen Worten: Du hast kein Recht, an den Mode-Bits etwas zu ändern, vermutlich weil die Dateien dem CGI-User nicht gehören.  
  
Vergleiche mal UID und GID der Dateien (Index 4 und 5 des stat-Rückgabewerts) mit UID, EUID, GID und EGID des Scripts ($<, $>, $( und $)).  
  
Alexander

-- 
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".

[Beat]

http://www.elcappuccino.ch/cgi/chmod/chmod.pl
Soll jemand auf den Link klicken? OK, da steht ein paar Mal "Operation not permitted", mit anderen Worten: Du hast kein Recht, an den Mode-Bits etwas zu ändern, vermutlich weil die Dateien dem CGI-User nicht gehören.
Vergleiche mal UID und GID der Dateien (Index 4 und 5 des stat-Rückgabewerts) mit UID, EUID, GID und EGID des Scripts ($<, $>, $( und $)).

Resultat:

CWD is: /home/elcappuccino.ch/cgi/chmod
$< = 30, $> = 30, $( = 65534 65534, $) = 65534 65534
exists /home/elcappuccino.ch/cgi/chmod
can read /home/elcappuccino.ch/cgi/chmod
can execute /home/elcappuccino.ch/cgi/chmod
Permissions: 0705 UID: 3900 GID: 100

FAILURE chmod 777 on /home/elcappuccino.ch/cgi/chmod/chmod.txt because of Operation not permitted
exists /home/elcappuccino.ch/cgi/chmod/chmod.txt
can read /home/elcappuccino.ch/cgi/chmod/chmod.txt
Permissions: 0604 UID: 3900 GID: 100

FAILURE chmod 606 on /home/elcappuccino.ch/cgi/chmod/chmod.txt because of Operation not permitted
exists /home/elcappuccino.ch/cgi/chmod/chmod.txt
can read /home/elcappuccino.ch/cgi/chmod/chmod.txt
Permissions: 0604 UID: 3900 GID: 100

[Alexander (HH)]

Moin Moin!

http://www.elcappuccino.ch/cgi/chmod/chmod.pl
Soll jemand auf den Link klicken? OK, da steht ein paar Mal "Operation not permitted", mit anderen Worten: Du hast kein Recht, an den Mode-Bits etwas zu ändern, vermutlich weil die Dateien dem CGI-User nicht gehören.
Vergleiche mal UID und GID der Dateien (Index 4 und 5 des stat-Rückgabewerts) mit UID, EUID, GID und EGID des Scripts ($<, $>, $( und $)).

Resultat:

CWD is: /home/elcappuccino.ch/cgi/chmod
$< = 30, $> = 30, $( = 65534 65534, $) = 65534 65534
exists /home/elcappuccino.ch/cgi/chmod
can read /home/elcappuccino.ch/cgi/chmod
can execute /home/elcappuccino.ch/cgi/chmod
Permissions: 0705 UID: 3900 GID: 100

[...]

Noch eindeutiger geht es nicht: Die Dateien gehören nicht dem User, unter dem das Script läuft, und auch die Gruppen passen nicht. Damit läßt dich kein unixoides System irgendetwas an den Attributen oder Inhalten drehen.

Wenn das ein Shared Hosting Server ist, solltest Du mal ein ernstes Wort mit dem Provider wechseln, denn offensichtlich läuft der Webserver ohne suexec oder Equivalent. Damit kann jeder Kunde mit eigenen CGIs überall da herumpfuschen, wo der Webserver-User (UID=30, GID=65534) Schreibrechte hat -- auch in Verzeichnissen anderer User. Zum Beispiel, weil ein Kunden-CGI irgendwo Schreibrechte braucht und der Kunde stumpf chmod 777 gemacht hat. Sollte der Provider nicht reagieren, solltest Du über einen anderen Provider nachdenken, der seine Server sicher konfiguriert hat.

Wenn das ein Managed Server ist, egal ob virtuell oder echte Hardware, müßtest Du root-Rechte haben (oder Dir verschaffen können) und das Problem selbst beheben können.

Wenn das ein Root-Server ist, egal ob virtuell oder echte HW, hast Du root-Rechte und kannst das Problem selbst beheben.

Ein vorübergehender Lösungsansatz wäre ein kleiner Wrapper (in C), der per setuid/setgid das CGI unter Deinem Account laufen läßt -- nicht schön, aber brauchbar. Siehe http://perldoc.perl.org/perlsec.html#Security-Bugs. Wichtig hierbei ist, dass der Script-Name fest eincompiliert ist und eben NICHT als Parameter oder per Environment übergeben wird, denn sonst könnte jeder Kunde jedes Programm unter Deinem Account laufen lassen!

Alexander

[Beat]

Wenn das ein Shared Hosting Server ist, solltest Du mal ein ernstes Wort mit dem Provider wechseln, denn offensichtlich läuft der Webserver ohne suexec oder Equivalent.

Offenbar. Aber der wird wegen mir nicht seine VHost-Server-Einrichtung ändern.

Damit kann jeder Kunde mit eigenen CGIs überall da herumpfuschen, wo der Webserver-User (UID=30, GID=65534) Schreibrechte hat -- auch in Verzeichnissen anderer User.

Zum Beispiel, weil ein Kunden-CGI irgendwo Schreibrechte braucht und der Kunde stumpf chmod 777 gemacht hat. Sollte der Provider nicht reagieren, solltest Du über einen anderen Provider nachdenken, der seine Server sicher konfiguriert hat.

Der plaudert ganz gewiss seine Setup-Details in der Paketbeschreibung aus ;)

Es ist ein stink normaler Massenhoster. Und es war mir bekannt, dass Perl nur die Rechte von user nobody hat. Habe ich übrigens ja schon im übrigen thread gesagt.
Für mich war das ein Versuch für einen Test, um das Unix-System etwas kennenzulernen. Das Auskommen bedeutet halt, dass mein CMS keine chmod-Fähigkeiten in nächster Zeit implementiert bekommt.

Ich bin mir nicht sicher, ob ein Setuid Wrapper Script die Lösung ist. Grund: Wenn ich das will, dann brauche ich den Wrapper für alle Scripte. Und dann muss ich bei jedem Script auch noch jeweils die Schreibrechte zuerst mit chmod einstellen und wieder ausschalten.
Erst dann kann ich überall die World-Rechte auf readonly setzen.

Ich sehe deshalb setuid als problematisch an. Wenn dir ein anderer einbricht hast du definitiv das grössere Problem.

Beziehe mich darauf http://www.xav.com/scripts/help/setuid.html

mfg Beat

[Alexander (HH)]

Moin Moin!

Wenn das ein Shared Hosting Server ist, solltest Du mal ein ernstes Wort mit dem Provider wechseln, denn offensichtlich läuft der Webserver ohne suexec oder Equivalent.

Offenbar. Aber der wird wegen mir nicht seine VHost-Server-Einrichtung ändern.

Hast Du wegen des Problems mit dem Provider Kontakt aufgenommen? Wenn ja, ist das ein Grund mehr, dort wegzugehen.

Damit kann jeder Kunde mit eigenen CGIs überall da herumpfuschen, wo der Webserver-User (UID=30, GID=65534) Schreibrechte hat -- auch in Verzeichnissen anderer User.

Zum Beispiel, weil ein Kunden-CGI irgendwo Schreibrechte braucht und der Kunde stumpf chmod 777 gemacht hat. Sollte der Provider nicht reagieren, solltest Du über einen anderen Provider nachdenken, der seine Server sicher konfiguriert hat.

Nochmal: Andere Kunden können in Deinem Webspace rumpfuschen, und Du kannst im Webspace anderer Kunden herumpfuschen, weil der Hoster zu blöd ist, den Webserver richtig aufzusetzen.

Ohne suexec (oder vergleichbare Systeme) zu arbeiten, also trotz mehrerer Kunden für alle CGIs den selben Account zu benutzen, funktioniert nur, so lange der Provider den CGIs vertrauen kann, nichts böses zu tun. Sprich: So lange der Provider es den Kunden NICHT erlaubt, eigene CGIs zu benutzen.

Der plaudert ganz gewiss seine Setup-Details in der Paketbeschreibung aus ;)

Manche vielleicht schon. Vor allem aber kannst Du mal nachfragen ("Unter welchem Account laufen CGIs? Unter meinem oder einem Sammel-Account für alle Kunden?"). Oder nach einem c't-Artikel der letzten zwei oder drei Jahre suchen, in dem unter anderem genau diese Isolation der Kunden voneinander getestet wurde.

Es ist ein stink normaler Massenhoster.

Nein, ein unterdurchschnittlich kompetenter.

Und es war mir bekannt, dass Perl nur die Rechte von user nobody hat. Habe ich übrigens ja schon im übrigen thread gesagt.

Technisch präziser: Perl wird vom Webserver mit den Rechten des nobody-Users gestartet. An Perl selbst hängen keine Rechte, es erbt die Rechte desjenigen Prozesses, der es aufgerufen hat.

Für mich war das ein Versuch für einen Test, um das Unix-System etwas kennenzulernen. Das Auskommen bedeutet halt, dass mein CMS keine chmod-Fähigkeiten in nächster Zeit implementiert bekommt.

Und dass jeder andere Kunde Deine Daten manipulieren und ggf. löschen kann.

Ich bin mir nicht sicher, ob ein Setuid Wrapper Script die Lösung ist.

Nein, suexec ist "die" Lösung. Der setuid-Wrapper ist nur eine Krücke, so lange Dein Hoster das grundlegende Problem seiner Systemkonfiguration nicht begriffen und beseitigt hat.

Der setuid-Wrapper verhindert nicht, dass andere Kunden über den Webserver Deine Scripte aufrufen und unter Deinem Account laufen lassen. Er verhindert aber, dass andere Kunden Zugriff auf die Dateien bekommen, auf die nur Deine Scripte Zugriff haben sollen. Deine Scripte paranoid genug zu programmieren, dass sie nichts "versehentlich" ausplappern, ist ein vollkommen anderes Problem, dessen Lösung mit "#!/usr/bin/perl -T" beginnt.

Grund: Wenn ich das will, dann brauche ich den Wrapper für alle Scripte.

Nicht notwendigerweise. Du brauchst für jedes Script, dass auf nicht-öffentliche Daten im Dateisystem zugreifen will, einen individuellen Wrapper. Scripte, die nur auf öffentliche Daten zugreifen oder gar nicht weiter mit Deinem Teil des Dateisystems interagieren, können weiterhin unter dem nobody-Account laufen.

Und dann muss ich bei jedem Script auch noch jeweils die Schreibrechte zuerst mit chmod einstellen und wieder ausschalten.

Was will mir dieser Satz sagen?

Mit dem Wrapper arbeiten die Scripte unter Deinem Account, warum willst Du an Zugriffsrechten rumschrauben?

Erst dann kann ich überall die World-Rechte auf readonly setzen.

Denk über diesen Satz bitte mal nach: Du hast die Rechte für bestimmte Verzeichnisse so eingestellt, dass JEDER NUTZER der Maschine dort schreiben kann. Und das gefällt Dir wirklich?

Ich würde an Deiner Stelle lieber heute als morgen den Provider wechseln.

Ich sehe deshalb setuid als problematisch an. Wenn dir ein anderer einbricht hast du definitiv das grössere Problem.

Nein, das riesige Problem ist das aktuelle Setup des Webservers. suexec würde das Problem vollständig lösen.

Ein setuid-Wrapper erlaubt es jedem Benutzer, ein Programm unter Deinem Account auszuführen. Aber eigentlich willst Du das Programm nur dann ausführen, wenn es vom Webserver gestartet wird. Also wird eine der ersten Aktionen des Wrappers sein, getuid(), getgid(), geteuid() und getegid() aufzurufen und mit den erwarteten, fest encompilierten Werten zu vergleichen und bei Abweichngen das Programm sofort zu beenden.

Wenn Du Dir die Doku des suexec-Helfers des Apachen mal genauer ansiehst, wirst Du feststellen, dass der genau das macht -- eine paranoide Prüfung der Umgebung und der Aufrufparameter.

Einen gefakten Aufruf über den Webserver, z.B. durch ein anderes CGI, wirst Du kaum verhindern können. Das ist auch relativ unproblematisch, denn Dein Script wird ja alle Eingaben und das Environment ausreichend paranoid prüfen, bevor es Daten verarbeitet oder ausgibt. Du könntest natürlich prüfen, ob der Parent-Prozess wirklich der Webserver ist, aber das ist nicht 100% sicher. Ein böswilliges, fremdes CGI kann immer noch das Environment, STDIN und STDOUT manipulieren, bevor es sich selbst per exec() durch Dein Script / Wrapper ersetzt.

Beziehe mich darauf http://www.xav.com/scripts/help/setuid.html

Da lese ich extrem wenig zu setuid-Wrappern, nur viel Halbwissen und Cargo Cult. Das Bißchen, das da steht, ist ziemlich alt und ziemlich dumm. Denn genau die notwendigen Tests der realen und effektiven User- und Group-IDs fehlen. Richtig ist, dass Perl im Taint-Mode betrieben werden sollte, wenn man mit Daten aus unsicheren Quellen arbeitet. Falsch dagegen ist wieder, dass diese Seite dass nur für Scripte empfiehlt, die über setuid-Wrapper gestartet werden. Richtig ist der Link auf die perlsec-Dokumentation, schöner wäre allerdings gewesen, auf eine aktuelle Fassung, z.B. http://perldoc.perl.org/perlsec.html, statt auf eine fast zehn Jahre alte 5.6.0-Version. Falsch ist wiederum die Aussage, man müsse $ENV{'PATH'} löschen. Das ist lang und breit in der Doku beschrieben, und PATH ist nicht die einzige kritische Environment-Variable. Von dem dort ebenfalls empfohlenen CGIWrap kann ich nur abraten, das sieht aus wie ein mißglückter Versuch, suexec nachzubauen.

Alexander

[Beat]

Was ist das Stichwort, das mir einen Apachen unter suexec _verrät_?
Ein Angebot mit Virtuellem Server?

mfg Beat

[Alexander (HH)]

Moin Moin!

Was ist das Stichwort, das mir einen Apachen unter suexec _verrät_?
Ein Angebot mit Virtuellem Server?

Das Stichwort ist suexec. Frag gezielt danach, ergänzt mit einer minimalen Beschreibung, was suexec macht ("CGIs unter meinem Account statt nobody oder wwwrun").

VServer sind eine völlig andere Geschichte, da mietest Du nicht nur einen Account und etwas Webspace, sondern ein ganzes Betriebssystem, wenn auch nur in einer virtuellen Maschine statt direkt auf echter Hardware. Entsprechend kannst Du Dich dann nahezu beliebig austoben, den Apachen ganz nach Deinen Wünschen konfigurieren oder durch einen anderen Webserver Deiner Wahl ersetzen. Der Haken an Root- und VServern ist, dass Du sehr genau wissen mußt, wie man das Betriebssystem absichert, sonst wird Dein (V)Server sehr schnell übernommen werden.

Alexander

[Beat]

Was ist das Stichwort, das mir einen Apachen unter suexec _verrät_?
Ein Angebot mit Virtuellem Server?

Das Stichwort ist suexec. Frag gezielt danach, ergänzt mit einer minimalen Beschreibung, was suexec macht ("CGIs unter meinem Account statt nobody oder wwwrun").

Ich habe auch aus Gründen mangelnden Webspaces den Provider angeschrieben.
Im alten Paket ist Suexec auf Kundenwunsch verfügbar.
Im neuen Paket ist es der Default.
Ich warte allerdings noch auf die Bestätigung wegen SFTP und sicherem Mailing für das neue Paket.

mfg Beat