Apache einrichten auf 15.6
Moin, es ist an der Zeit, dass ich auf meinem Leap den Apache ans laufen kriege. Da ich das nun nicht wirklich oft mache und das letzte mal auch auf Debian-Systemen, stehe ich wie immer etwas fragend da. Apache ist installiert und läuft. Alle(?) Docs sagen, wenn ich jetzt im Browser 'localhost' aufrufe, dass da eine Seite angezeigt werden würde, die sagt "It works!". Tja, '/srv/www/htdocs/' ist bei mir leer und daher wird nichts angezeigt. 1) Da ist dann als erstes die Frage, ob ich da was vergessen habe zu installieren. Ich denke nicht, bin aber nicht sicher. 2) laut uid.conf läuft Apache als wwwrun:www. Sind die Verzeichnisse unter '/srv/www/...' dann mit diesen UID und GID anzulegen? Bei mir ist das nach der Installation alles root:root. 3) Die Einrichtung über Yast meckert bzgl. des Networkmanagers. Gibt es damit wirklich Probleme oder ist die Meldung nur ein Hosenträger? Soweit so schlecht. Der Apache soll übrigens nur im internen Heimnetz lauschen. Joachim
Am Sonntag, dem 15.12.2024 um 13:17 +0100 schrieb Joachim Hussong:
Moin, Grüß Dich
es ist an der Zeit, dass ich auf meinem Leap den Apache ans laufen kriege. Da ich das nun nicht wirklich oft mache und das letzte mal auch auf Debian-Systemen, stehe ich wie immer etwas fragend da.
Apache ist installiert und läuft. Alle(?) Docs sagen, wenn ich jetzt im Browser 'localhost' aufrufe, dass da eine Seite angezeigt werden würde, die sagt "It works!". Tja, '/srv/www/htdocs/' ist bei mir leer und daher wird nichts angezeigt.
1) Da ist dann als erstes die Frage, ob ich da was vergessen habe zu installieren. Ich denke nicht, bin aber nicht sicher.
Bei mir ist da nach der Installation auch nichts. Scheints hielten die Macher des Apachepakets diese Seite für überflüssig.
2) laut uid.conf läuft Apache als wwwrun:www. Sind die Verzeichnisse unter '/srv/www/...' dann mit diesen UID und GID anzulegen? Bei mir ist das nach der Installation alles root:root.
Ja. Doch bei rein statischen Seiten ist es wohl egal. Hauptsache Apache kann die Dateien lesen. Aber PHP-Skripte werden wohl mit dem Benutzer wwwrun:www ausgeführt. Die müssen möglicherweise etwas schreiben, dann wird der Besitzer wichtig.
3) Die Einrichtung über Yast meckert bzgl. des Networkmanagers. Gibt es damit wirklich Probleme oder ist die Meldung nur ein Hosenträger?
Dazu kann ich nichts sagen. Tschüß, Volker
Hallo, Am 15.12.24 um 13:17 schrieb Joachim Hussong:
Apache ist installiert und läuft. Alle(?) Docs sagen, wenn ich jetzt im Browser 'localhost' aufrufe, dass da eine Seite angezeigt werden würde, die sagt "It works!". Tja, '/srv/www/htdocs/' ist bei mir leer und daher wird nichts angezeigt.
Du musst noch das Paket apache2-example-pages installieren. Dann sind auch die erforderlichen Seiten in /srv/www/htdocs vorhanden. Patrick
Am 15.12.24 um 13:28 schrieb Patrick Flügel:
Du musst noch das Paket apache2-example-pages installieren. Dann sind auch die erforderlichen Seiten in /srv/www/htdocs vorhanden.
Danach hatte ich ja gesucht, doch nichts in Yast gefunden. Sind die überhaupt noch im Repo? Sieht erst mal nicht so aus? Ich finde nur 'apache-commons-vfs-examples'
Am 15.12.24 um 13:32 schrieb Joachim Hussong:
Am 15.12.24 um 13:28 schrieb Patrick Flügel:
Du musst noch das Paket apache2-example-pages installieren. Dann sind auch die erforderlichen Seiten in /srv/www/htdocs vorhanden.
Danach hatte ich ja gesucht, doch nichts in Yast gefunden. Sind die überhaupt noch im Repo? Sieht erst mal nicht so aus? Ich finde nur 'apache-commons-vfs-examples'
bei meiner Installation von Leap 15.6 ist das Paket apache2-example-pages vorhanden. Allerdings gibt es laut https://software.opensuse.org/package/apache2-example-pages?search_term=apac... keine Unterstützung mehr für das Paket. Das finde ich merkwürdig.
Am 15.12.24 um 13:50 schrieb Patrick Flügel:
Am 15.12.24 um 13:32 schrieb Joachim Hussong:
Am 15.12.24 um 13:28 schrieb Patrick Flügel:
Du musst noch das Paket apache2-example-pages installieren. Dann sind auch die erforderlichen Seiten in /srv/www/htdocs vorhanden.
Danach hatte ich ja gesucht, doch nichts in Yast gefunden. Sind die überhaupt noch im Repo? Sieht erst mal nicht so aus? Ich finde nur 'apache-commons-vfs-examples'
bei meiner Installation von Leap 15.6 ist das Paket apache2-example-pages vorhanden. Allerdings gibt es laut https://software.opensuse.org/package/apache2-example-pages?search_term=apac... keine Unterstützung mehr für das Paket. Das finde ich merkwürdig.
Theophila:/etc/apache2/vhosts.d # zypper in apache2-example-page2 Repository-Daten werden geladen... Installierte Pakete werden gelesen... Paket 'apache2-example-pages' nicht gefunden. Paketabhängigkeiten werden aufgelöst... Keine auszuführenden Aktionen. Theophila:/etc/apache2/vhosts.d # Theophila:/etc/apache2/vhosts.d # cat /etc/os-release NAME="openSUSE Leap" VERSION="15.6" hmmmm ???? In welchem Repo wäre das denn zu finden?
On Sonntag, 15. Dezember 2024 13:55:09 Mitteleuropäische Normalzeit Joachim Hussong wrote:
apache2-example
https://software.opensuse.org/package/apache2-example-pages Gips nimmer.
Am 15.12.24 um 14:03 schrieb mh@mike.franken.de:
On Sonntag, 15. Dezember 2024 13:55:09 Mitteleuropäische Normalzeit Joachim Hussong wrote:
apache2-example
https://software.opensuse.org/package/apache2-example-pages
Gips nimmer.
OK, gut zu wissen, bin net blöd! zumindest was das hier angeht ;-)
Am 15.12.24 um 14:03 schrieb mh@mike.franken.de:
On Sonntag, 15. Dezember 2024 13:55:09 Mitteleuropäische Normalzeit Joachim Hussong wrote:
apache2-example
https://software.opensuse.org/package/apache2-example-pages
Gips nimmer.
ja, scheint so. Aber man kann sich die drei Dateien, die das Verzeichnis /srv/www/htdocs enthält selbst anlegen: paddy@balu:/srv/www/htdocs$ ll insgesamt 20 drwxr-xr-x 2 root root 4096 15. Dez 13:23 ./ drwxr-xr-x 4 root root 4096 20. Jun 13:19 ../ -rw-r--r-- 1 root root 302 23. Jul 2008 favicon.ico -rw-r--r-- 1 root root 45 11. Jun 2007 index.html -rw-r--r-- 1 root root 26 13. Nov 08:45 robots.txt paddy@balu:/srv/www/htdocs$ cat index.html <html><body><h1>It works!</h1></body></html> paddy@balu:/srv/www/htdocs$ cat robots.txt User-Agent: * Disallow: / paddy@balu:/srv/www/htdocs$ wobei favicon.ico wohl auch weggelassen werden kann.
Am 15.12.24 um 14:11 schrieb Patrick Flügel:
Am 15.12.24 um 14:03 schrieb mh@mike.franken.de: ja, scheint so. Aber man kann sich die drei Dateien, die das Verzeichnis /srv/www/htdocs enthält selbst anlegen:
Mir ging es nur darum, ob ich nicht was vergessen habe zu installieren, was sich evtl. durch die fehlende(n) Beispieldatei(en) äußert. Die Dateien selbst sind unwichtig, da ich meine eigenen habe. Die zwei Sachen hatten mich verwirrt: 1) Benutzer und Gruppe der Dateien unter 'srv/www/'. Warum nicht gleich wwwrun:www sondern root:root, was ja nirgends empfohlen wird? Macht ja auch eigentlich keinen Sinn. 2) Und die Diskrepanz zwischen der Dokumentation (https://doc.opensuse.org/documentation/leap/reference/html/book-reference/ch...) und der Realität. Die Dokumentation bezieht sich explizit auf 15.6! Nun gut. Hat sich alles geklärt. Joachim
On Sonntag, 15. Dezember 2024 14:41:51 Mitteleuropäische Normalzeit Joachim Hussong wrote:
Am 15.12.24 um 14:11 schrieb Patrick Flügel:
Am 15.12.24 um 14:03 schrieb mh@mike.franken.de:
ja, scheint so. Aber man kann sich die drei Dateien, die das Verzeichnis /srv/www/htdocs enthält selbst anlegen: Mir ging es nur darum, ob ich nicht was vergessen habe zu installieren, was sich evtl. durch die fehlende(n) Beispieldatei(en) äußert.
Die Dateien selbst sind unwichtig, da ich meine eigenen habe.
Die zwei Sachen hatten mich verwirrt:
1) Benutzer und Gruppe der Dateien unter 'srv/www/'. Warum nicht gleich wwwrun:www sondern root:root, was ja nirgends empfohlen wird? Macht ja auch eigentlich keinen Sinn.
2) Und die Diskrepanz zwischen der Dokumentation (https://doc.opensuse.org/documentation/leap/reference/html/book-refer ence/cha-apache2.html) und der Realität. Die Dokumentation bezieht sich explizit auf 15.6!
aber da steht doch: By default in openSUSE Leap, the DocumentRoot directory /srv/www/htdocs and the CGI directory /srv/www/cgi-bin belong to the user and group root. You should not change these permissions. If the directories are writable for all, any user can place files into them. These files might then be executed by Apache with the permissions of wwwrun, which may give the user unintended access to file system resources. Use subdirectories of /srv/www to place the DocumentRoot and CGI directories for your virtual hosts and make sure that directories and files belong to user and group root.
Nun gut. Hat sich alles geklärt.
Joachim
Ciao. Michael.
Am 15.12.24 um 15:12 schrieb mh@mike.franken.de:
aber da steht doch:
By default in openSUSE Leap, the DocumentRoot directory /srv/www/htdocs and the CGI directory /srv/www/cgi-bin belong to the user and group root.
Also alles bei root:root belassen!
You should not change these permissions. If the directories are writable for all, any user can place files into them. These files might then be executed by Apache with the permissions of wwwrun, which may give the user unintended access to file system resources.
ändere keine Berechtigungen, besonders keine Schreibrechte für 'all'! Apache selbst nicht, aber seine Unterprozesse laufen als wwwrun:www? Ist das so zu verstehen? Der Benutzer 'wwwrun' und seine Gruppe 'www' müssen ja irgendeinem Zweck dienen.
Use subdirectories of /srv/www to place the DocumentRoot and CGI directories for your virtual hosts and make sure that directories and files belong to user and group root.
s.o.
Am 15.12.24 um 16:15 schrieb Joachim Hussong:
Apache selbst nicht, aber seine Unterprozesse laufen als wwwrun:www? Ist das so zu verstehen? Der Benutzer 'wwwrun' und seine Gruppe 'www' müssen ja irgendeinem Zweck dienen.
Apache läuft klassich als root um Zugriff auf Ports < 1024 zu haben (also z.B. 80 und 443), wechselt nach Starten des Listeners dann für den Rest der Veranstalung auf wwwrun. wwwrun braucht in aller Regel keinen Schreibzugriff auf's DocumentRoot, irgendwelche Apps (ala php) schreiben in einer idelaen Welt außerhalb vom DocumentRoot. Viele Grüße Ulf
Am Sonntag, 15. Dezember 2024, 16:53:37 CET schrieb Ulf Volmer:
wwwrun braucht in aller Regel keinen Schreibzugriff auf's DocumentRoot, irgendwelche Apps (ala php) schreiben in einer idelaen Welt außerhalb vom DocumentRoot.
Oder man erteilt wwwrun nur auf den jeweiligen Unterverzeichnissen Schreibzugriff, wo er benötigt wird. Grüße Richard
On Sonntag, 15. Dezember 2024 17:04:59 Mitteleuropäische Normalzeit Richard Hafenscher wrote:
Am Sonntag, 15. Dezember 2024, 16:53:37 CET schrieb Ulf Volmer:
wwwrun braucht in aller Regel keinen Schreibzugriff auf's DocumentRoot, irgendwelche Apps (ala php) schreiben in einer idelaen Welt außerhalb vom DocumentRoot.
Oder man erteilt wwwrun nur auf den jeweiligen Unterverzeichnissen Schreibzugriff, wo er benötigt wird.
man erteilt wwwrun *niemals* Schreibzugriff unterhalb DocumentRoot, weil man sonst ein Einfallstor für alles (Un)mögliche aufreißt. Apache mit seinen ganzen Modulen ist eh schon ein Security-Alptraum, wenn man nicht genau weiß, was man tut. Das sieht man ja auch immer wieder an großen Websites, die auf einmal ihre Benutzerdatenbank "verlieren" oder deren Startseite ausgetauscht wurde.
Grüße
Richard
Ciao. Michael.
Am Sonntag, dem 15.12.2024 um 17:44 +0100 schrieb mh@mike.franken.de:
On Sonntag, 15. Dezember 2024 17:04:59 Mitteleuropäische Normalzeit Richard Hafenscher wrote:
Am Sonntag, 15. Dezember 2024, 16:53:37 CET schrieb Ulf Volmer:
wwwrun braucht in aller Regel keinen Schreibzugriff auf's DocumentRoot, irgendwelche Apps (ala php) schreiben in einer idelaen Welt außerhalb vom DocumentRoot.
Oder man erteilt wwwrun nur auf den jeweiligen Unterverzeichnissen Schreibzugriff, wo er benötigt wird.
man erteilt wwwrun *niemals* Schreibzugriff unterhalb DocumentRoot, weil man sonst ein Einfallstor für alles (Un)mögliche aufreißt. Apache mit seinen ganzen Modulen ist eh schon ein Security-Alptraum, wenn man nicht genau weiß, was man tut. Das sieht man ja auch immer wieder an großen Websites, die auf einmal ihre Benutzerdatenbank "verlieren" oder deren Startseite ausgetauscht wurde.
Das glaube ich aber so nicht. Tiki hat ein Skript setup.sh, das man als root aufruft. Es setzt dann u.a. die richtigen Besitzer und Rechte innerhalb des Tiki-Verzeichnisbaums. Der Besitzer unter Ubuntu ist www-data:www-data. Tiki *braucht* Schreibzugriff auf Teile seines Verzeichnisbaums, sonst könnte man z.B. keine Dateien hochladen (sofern eingestellt wurde, daß die im Dateisystem gespeichert werden und nicht in der Datenbank). Natürlich darf man keine Schreibrechte für Andere (other) gewähren. Aber ich sehe nicht, wie ein Angreifer ein Programm hochladen und dann mit wwwrun- Rechten ausführen kann, wenn die Website das Hochladen nicht ausdrücklich vorsieht (so wie bei Tiki). Ich weiß jetzt nicht, wie Tiki die hochgeladenen Dateien davor schützt, abgerufen und dann ausgeführt zu werden. (Ich speichere meine Dateien in der Datenbank.) Aber es gibt eine längliche .htaccess-Datei, in der sowas geregelt wird. Tiki ist ein professionelles, umfangreiches Program (Wiki/CMS/Groupware), das es schon lange gibt und das stetig weiterentwickelt wird. Daß da offensichtliche Sicherheitslücken aufgerissen werden, kann ich mir nicht vorstellen. Unter Ubuntu ist es der Normalfall, daß die Dateien www-data:www-data gehören (ohne Schreibrechte für die Gruppe und Andere). Daß man sie root übereignen soll, habe ich noch nie gehört. Ich pflege allerdings nur meinen eigenen, privaten Apache. Viele Grüße, Volker
Am 16.12.24 um 14:25 schrieb Volker Wysk:
Unter Ubuntu ist es der Normalfall, daß die Dateien www-data:www-data gehören (ohne Schreibrechte für die Gruppe und Andere). Daß man sie root übereignen soll, habe ich noch nie gehört.
Soweit ich das überblicke, machen Debian und seine Derivate (Ubuntu, Raspian, etc.) das so mit www-run also nicht root. Daher kam bei mir die Frage ja hoch. Wenn OpenSuse da einen anderen Schlitten fährt, soll's mir recht sein, die werden sich was dabei gedacht haben. Genauso wie die Debianer. Ich mag nicht behaupten, die ein oder andere Art wäre falsch. Sie ist nur anders, teilweise viel anders. Vlt kann der ein oder andere die beiden Varianten gegeneinander stellen und erklären, was die Vor- und Nachteile der jeweiligen Variante sind, bzw. die Argumente von Debian und die von OpenSuse. Das würde mich interessieren.
Am Montag, 16. Dezember 2024, 14:25:24 CET schrieb Volker Wysk:
Am Sonntag, dem 15.12.2024 um 17:44 +0100 schrieb mh@mike.franken.de:
On Sonntag, 15. Dezember 2024 17:04:59 Mitteleuropäische Normalzeit
Richard Hafenscher wrote:
Am Sonntag, 15. Dezember 2024, 16:53:37 CET schrieb Ulf Volmer:
wwwrun braucht in aller Regel keinen Schreibzugriff auf's DocumentRoot, irgendwelche Apps (ala php) schreiben in einer idelaen Welt außerhalb vom DocumentRoot.
Oder man erteilt wwwrun nur auf den jeweiligen Unterverzeichnissen Schreibzugriff, wo er benötigt wird.
man erteilt wwwrun *niemals* Schreibzugriff unterhalb DocumentRoot, weil man sonst ein Einfallstor für alles (Un)mögliche aufreißt. Apache mit seinen ganzen Modulen ist eh schon ein Security-Alptraum, wenn man nicht genau weiß, was man tut. Das sieht man ja auch immer wieder an großen Websites, die auf einmal ihre Benutzerdatenbank "verlieren" oder deren Startseite ausgetauscht wurde.
Das glaube ich aber so nicht. Tiki hat ein Skript setup.sh, das man als root aufruft. Es setzt dann u.a. die richtigen Besitzer und Rechte innerhalb des Tiki-Verzeichnisbaums. Der Besitzer unter Ubuntu ist www-data:www-data.
Tiki *braucht* Schreibzugriff auf Teile seines Verzeichnisbaums, sonst könnte man z.B. keine Dateien hochladen (sofern eingestellt wurde, daß die im Dateisystem gespeichert werden und nicht in der Datenbank).
Natürlich darf man keine Schreibrechte für Andere (other) gewähren. Aber ich sehe nicht, wie ein Angreifer ein Programm hochladen und dann mit wwwrun- Rechten ausführen kann, wenn die Website das Hochladen nicht ausdrücklich vorsieht (so wie bei Tiki).
Ich weiß jetzt nicht, wie Tiki die hochgeladenen Dateien davor schützt, abgerufen und dann ausgeführt zu werden. (Ich speichere meine Dateien in der Datenbank.) Aber es gibt eine längliche .htaccess-Datei, in der sowas geregelt wird.
Tiki ist ein professionelles, umfangreiches Program (Wiki/CMS/Groupware), das es schon lange gibt und das stetig weiterentwickelt wird. Daß da offensichtliche Sicherheitslücken aufgerissen werden, kann ich mir nicht vorstellen.
Unter Ubuntu ist es der Normalfall, daß die Dateien www-data:www-data gehören (ohne Schreibrechte für die Gruppe und Andere). Daß man sie root übereignen soll, habe ich noch nie gehört. Ich pflege allerdings nur meinen eigenen, privaten Apache.
Viele Grüße, Volker
Auch andere Applikationen erfordern Schreibzugriff in Bereichen im Webroot. Bspw. Nextcloud gibt vor, das gesamte Root dem Apache-User zu geben. Es bietet die Möglichkeit, ein Update oder Plugin-Installationen über die Weboberfläche zu machen. So muss die Applikation auch überall schreiben können. Auch die config.php wird über die Webapp angepasst. Dafür wird ein vorkonfiguriertes .htaccess mitgeliefert, das die Zugriffe über Web entsprechend regelt und für die Webserver Konfiguration wird "AllowOverride All" vorgegeben. Grüße Richard
Am 16.12.24 um 23:33 schrieb Richard Hafenscher:
Bspw. Nextcloud gibt vor, das gesamte Root dem Apache-User zu geben.
Mein Nextcloud hier gehört dem root- User, nur data, config und app dem Apache User. NC Updates mache ich per Script. Das ist immer noch nicht der Idelazustand (warum müssen app und config im DocumentRoot liegen?), aber besser wie nix. Viele Grüße Ulf
participants (6)
-
Joachim Hussong -
mh＠mike.franken.de -
Patrick Flügel -
Richard Hafenscher -
Ulf Volmer -
Volker Wysk