[HOWTO]wwwrun-Problem beheben/umgehen ohne Serverumstellung

**Antestor** · 07.04.2010 09:37

Hm, ich will dir nicht widersprechen, mir ist nur unklar:

1. Ist "nobody" ein global agierender User?? Es ist der standardmäßige Benutzer des Webpacks, der woanders wwwrun oder wwwdata heißt. Nobody != everybody, oder?

2. Wo genau liegt das Problem. Ich habe schon mehrere Threads durchgelesen zu dem Thema. Aber kann man nicht zusammenfassend sagen, dass das Problem IMMER Schwachstellen in dem CMS voraussetzt?

Wenn Joomla stabil ist und ständig aktualisiert wird, kann doch auch der global agierende User nichts einschleusen, oder? Die schwache Stelle ist doch immer das CMS selbst!?

Und noch eine Frage: Ist es sicherer, als Owner das Webpaket anzugeben (also einen eindeutigen Benutzer) und als Gruppe "nobody"? Oder ist das das gleiche?

Ansonsten habe ich mal bei einem anderen CMS die 2. Variante des Work-arounds probiert. Die funktioniert bei mir ganz gut!

Alternative wäre sonst ein VServer bei HostEurope, wo PHP als CGI läuft. Ist das sinnvoller? Hört man auch verschiedene Meinungen drüber. Oder kann man das Benutzerproblem bei einem VServer bei HE mittlerweile eleganter lösen?

**Chris1308** · 07.04.2010 12:15

Hi zusammen,

ich habe auch noch eine Verständnisfrage und hoffe das ihr mir helfen könnt.
Bin auch bei Hosteurope und habe damit ebenfalls das wwwrun-Problem.

Frage:
Wo ist denn jetzt genau der Unterschied bzgl. der Sicherheit zwischen PHP per CGI und den Besitzer des Joomlaordners auf nobody zu setzen?
Bei beiden Konfigurationen hat der PHP-Nutzer doch die Rechte auf die Dateien des Joomlaverzeichnisses und kann diese ändern. Nur dass durch das Setzen der Berechtigungen auf nobody nur PHP die Rechte hat und man als FTP-Nutzer in die Röhre schaut, bzw. bei der PHP per CGI-Lösung beide Zugriff haben?

Oder habe ich da jetzt was falsch verstanden?
Bitte um Aufklärung.

Viele Grüße
Chris

**Rooney** · 07.04.2010 14:23

Zitat von Chris1308

Wo ist denn jetzt genau der Unterschied bzgl. der Sicherheit zwischen PHP per CGI und den Besitzer des Joomlaordners auf nobody zu setzen?

Im Prinzip ist, bei richtig konfigurierten Servern, nichts sicherer oder unsicherer. Oft werden aber bei Problemen mit den unterschiedlichen Benutzergruppen von Joomla und FTP langfristig auf Grund der Bequemlichkeit PHP-Sicherheitsfunktionen abgeschaltet oder Verzeichnisrechte unsicher gesetzt. DANN wird das ganze unsicher (z.B. das Setzen von Ordnerrechten auf 777).

Nachzulesen hier: https://www.fc-hosting.de/cms/joomla_perfekt.php

Eine schöne Erklärung findet sich auch hier: http://www.joomla-tutorials.de/frage...-erklaert.html

Rooney

Rooney

**flotte** · 07.04.2010 18:29

Zitat von Antestor

1. Ist "nobody" ein global agierender User?? Es ist der standardmäßige Benutzer des Webpacks, der woanders wwwrun oder wwwdata heißt. Nobody != everybody, oder?

Ja ist globaler User des Webservers. Heisst auf unterschiedlichen Linux-Distributionen unterschiedlich (nobody, www-data, wwwrun etc.).

Zitat von Antestor

2. Wo genau liegt das Problem. Ich habe schon mehrere Threads durchgelesen zu dem Thema. Aber kann man nicht zusammenfassend sagen, dass das Problem IMMER Schwachstellen in dem CMS voraussetzt?

Wenn Joomla stabil ist und ständig aktualisiert wird, kann doch auch der global agierende User nichts einschleusen, oder? Die schwache Stelle ist doch immer das CMS selbst!?

Es geht hier nicht nur um das eigene Web, sondern auch die anderen Webs auf einem Server. Das ist der entscheidene Punkt!!
Wenn irgendwo anders eine Lücke ist und ein Hackerscript Zugang bekommt, dann kann es ziemlich mühelos nicht nur das betroffenen Web hacken, sondern auch andere auf der Maschine. Keinerlei Dateirechte können hier so einen Zugriff stoppen, denn alle Dateien aller Webs gehören ja demselben User!!
Es gibt noch andere Einschränkungen des Zugriffsbereichs von PHP, wie das open_basedir. Das ist ein NUR auf PHP-Ebene wirkender Schutz und ist daher nur begrenzt wirksam. Aufgerufene Binaries oder Perlscripte interessieren sich nämlich nicht für in PHP wirkende Restriktionen.

**Antestor** · 07.04.2010 19:34

Ok danke! Ich werde dann wohl den 2. Workaround nutzen und nur über den FTP Layer arbeiten. Für die Joomla Sachen auf meinem Web ist das nicht so dramatisch, sind keine Kunden-Webs, nur private...

Trotzdem find ich es dann schon sehr seltsam, dass der Support von HE mir den Tipp mit dem Nobody gibt und meint das wäre sicher... Seltsam auch, dass HE groß damit wirbt, wie einfach man Joomla auf deren Webs installieren kann

Werd mir in Zukunft dann mal ein Webpaket suchen wo Joomla vernünftig läuft. Vielleicht lande ich ja dann bei fc

**Antestor** · 09.05.2011 13:26

Hab gerade einen Newsletter von Hosteurope bekommen, dass sie das Dateisystem jetzt so umgestellt haben, dass das wwwrun-Problem behoben ist.

**DannyJoomla** · 25.01.2012 12:30

Hallo Joomla-Freunde,

ich bitte euch dringend um Hilfe.

Habe das wwwrun-Problem und daher die Lösung 1 hier angewandt. Punkt 8 (Entpacken) läßt sich nicht ausführen:

Leider kann ich die gezippte Joomla 2.5 Datei (Joomla_2.5.0-Stable-Full_Package_German.zip) nicht mit Extplorer entpacken. (extract_failure - Unable to open archive: Zip File Function error: Read error)
Testweise kann ich die akeeba-backup-3.3.6-core.zip auch nicht entpacken. (extract_failure - Unable to write entry: /var/www/web82/html/akeeba.xml)

Umbenennen der Dateien ist auch nicht möglich.

Habe die scripts.tar.gz nach extplorer/scripts entpackt. Kann da der Fehler liegen?

Ich bitte euch um eure Hilfe.

Danke schon mal vorab.

Schöne Grüße
Danny

**DannyJoomla** · 25.01.2012 15:05

So, hab jetzt Lösung 2 gemacht:
Die hat auf Anhieb funktioniert.

... und akeeba-backup-3.3.6-core.zip wurde problemlos installiert.

**Arni** · 25.01.2012 15:07

.. hättest du aber auch gleich die aktuellste Version 3.3.11 nehmen können!

**DannyJoomla** · 30.01.2012 10:02

Danke für den Hinweis

Thema: [HOWTO]wwwrun-Problem beheben/umgehen ohne Serverumstellung

LinkBack

Themen-Optionen

Thema durchsuchen

Anzeige

Erhielt Danksagungen von:

Lesezeichen

Lesezeichen

Berechtigungen