textpattern ohne Leserechte

S

seblueye

Well-Known Member
Ich habe über die FreeBSD-ports textpattern installiert
(und auch mysql-51-server&client)

jetzt würde ich gern das textpattern-setup ausführen
(also webserverIP/textpattern/setup )
Leider kommt ständig der folgende Fehler

Forbidden
You don't have permission to access /textpattern on this server.

Ich glaube man muss die .htaccess im /usr/local/www/textpattern
etwas ändern.
ich habe schon folgendes probiert und den Rechner neugestartet

Order Deny,Allow
Allow from all
Satisfy any

leider habe ich immernoch keine Leserechte um textpattern zu starten und es kommt die oben genannte Fehlermeldung ("Forbidden")

Was mache ich falsch
Danke
 
Überprüf erstmal die Zugriffs- / Eigentümerrechte des Verzeichnisses mit ls -la
 
hab ich auch schon geprüft.

drwxr-xr-x 11 root wheel 512 19 Jul 02:25 textpattern

drwxr-xr-x 2 root wheel 512 19 Jul 02:25 setup

sollte doch glaube ich für alle lesbar sein ..
 
Ich kenne das Teil nicht aber, root / wheel würd ich nicht verwenden, sieh Dir din Eigtümer / die Gruppe von www odgl. an.
Ja lesen schon - wo will das Ding hinschreiben ... wenn da rein, dann is nicht, gehört ja root.
 
Du hast recht mit dem root-user.
Ich hab schon einen neuen User angelegt,
aber erstmal müsste es ja mit root funktionieren.
Noch andere Ideen?
 
Es funktioniert, wenn Dein Apache als root läuft - macht er aber nicht.
Ändere owner / group zu dem, was bei www eingetragen ist. Ich weiß jetzt nicht, welcher user verwendet wird, selbiger ist aber nicht in der Gruppe wheel. Root / wheel ist ein Sicherheitsrisiko bei öffentlich zugänglichen Diensten.
 
Ich kenne textpattern nicht, aber es liest sich so als ob es etwas wäre was im Webbrowser läuft. Da dieser mit dem Benutzer www:www läuft solltest du die Rechte der Dateien dahingehend ändern. Der root-user führt es in dem Falle ja nicht aus, sondern der Webserver
 
Und, trenne Dich vom neu angelegten User, wenn Du ihn nicht brauchst. Wie @Rakor schrieb verwende www:www den gibts nicht umsonst.
 
Als was der Webserver läuft, ist doch völlig egal. Wenn der Pfad und alle Dateien für jeden lesbar sind, dann wohl auch für den Webserver.

Was sagt denn das errorlog vom Webserver? Ist vielleicht irgendwelcher chroot-Kram am Werk, so dass der Webserver eine andere Vorstellung vom Pfad hat?
 
Zum lesen schon, da das Ding aber anscheinend eine art CMS ist, beim schreiben aber nicht. Man könnte es testweise auch mit 777 probieren - dann bleibt aber ein potentielles Sicherheitsloch offen.
 
Um das Ding selbst geht es doch noch gar nicht. Die Meldung kommt vom Webserver, also ist da erstmal Handlungsbedarf.

Es wäre übrigens sehr unsauber, wenn eine Webapplikation in ihr Verzeichnis schreiben will. Das Ding hat ne Datenbankanbindung und Temp-Kram wird von PHP ja wohl auch nicht ins WWW-Verzeichnis gemalt sondern nach /tmp oder so. Die Anwendung sollte nie durch sich selbst beschreibbar sein.
 
Da gebe ich Dir recht.
Ich hätte es einfach - als kleinsten gemeinsamen Nenner - damit probiert www:www zu probieren - evtl. hätten sich damit alle Probleme von selbst gelöst. Root / wheel sollte es definitv nicht sein.
Der Rest liegt beim Fragenden.
 
root:wheel sollte es deswegen nicht sein, weil dadurch der Webserver nur über "other" Zugriff hat, was gleichzeitig heißt, dass jeder User auf dem System Zugriff hat.

Es ist prinzipiell richtig, dass das Webverzeichnis und alle Dateien am Ende optimalerweise rwxr-x--- bzw. rw-r----- root:www sein sollten, damit nur der Webserver Lesezugriff hat und nur root Dateien verändern kann. www:www sollten sie nicht sein.

Edit: Also nochmal zur Klarstellung. So sollte man es am Ende optimalerweise eingerichtet haben und besser ist es natürlich, wenn man es von vornherein so macht. Das hat aber alles mit dem konkreten Problem nur am Rande zu tun. rwxr-xr-x root:wheel muss genauso funktionieren, sonst funktioniert auch rwxr-x--- root:www nicht. Das Problem liegt noch woanders.
 
also nun hab ich alles Dateien und Verzeichnisse in /usr/local/www/textpattern dem user www:www hinzugefügt.
geht dennoch noch nicht: immer wieder:

Forbidden
You don't have permission to access /textpattern on this server.
 
nach der installation über die ports (die ich nicht als www-user machen konnte sondern nur über den root-user)
wurde noch folgendes angezeigt.
wielleicht hilf das noch bei der lösung des problems

Installing textpattern-4.2.0...
-----------------------------------------------------------
textpattern has been installed into:

/usr/local/www/textpattern

You will probably want to add an alias to your httpd.conf file,
something like this:

Alias /textpattern "/usr/local/www/textpattern"

For initial setup:

- Setup an empty mysql database
- Open web browser and browse textpattern directory
http://yourserver/textpattern/setup/
- Follow steps on setup wizard

-----------------------------------------------------------
 
Es gibt durchaus einige php-basierte Webanwendungen die Schreibrechte in ihrem Ordner benötigen. Alle die Dateien ablegen, ihre Daten nicht in Datenbanken schreiben (sondern ein Dateien z.B. Dokuwiki) oder die ihre Konfiguration ablegen wollen (so ziemlich alle die ich bisher hatte).
 
Dann ist aber hoffentlich der Datenbereich getrennt von den Anwendungsdaten, also ein Unterverzeichnis, was man dann separat rwx setzen kann. Ich kann mir nicht vorstellen, dass es Webanwendungen gibt, die einfach zwischen ihren Anwendungsdateien rummalen.
 
seblueye schrieb:
Order Deny,Allow
Allow from all
Satisfy any
Zum Vergrößern anklicken....

Hmm, welcher Apache läuft denn da?
Was steht in der Datei /var/log/httpd-error.log?

Wenn du textpattern unterhalb /usr/local/www/textpattern installiert hast, versuche mal folgenden Block:

<Directory /usr/local/www/textpattern>
Require all granted (Apache 2.4)
Allow from all (Apache 2.2)
</Directory>

Aber wie gesagt, bitte die Fehlermeldung aus /var/log/httpd-error.log posten, dort steht genau drin, was zu tun ist.

Rob
 
Also kann die Anwendung, für die gerade ein Advisory mit Patch rauskam, sich selbst updaten.

Die Anwendung.

Die, die nicht mehr vertrauenswürdig ist, weil eine Lücke entdeckt wurde.

Der vertraut man, sich selbst upzudaten.

Wem sich da nicht die Zehennägel hochrollen, sollte eigtl keine Server betreiben. Aber was weiß ich schon..

Edit: Wenn ich keine Sicherheit habe, dass die Anwendung sich nicht selbst modifizieren kann, muss ich doch quasi bei jeder entdeckten Lücke die Anwendung komplett in die Tonne hauen und neuinstallieren, sonst schleppe ich doch tatsächlich ausgenutzte Lücken ewig mit. So kann man doch unmöglich einen Server betreiben.
 
Wieso? Die Anwendung kann doch mit niedrigen Rechten laufen und nur sich selbst kaputt machen.
Die Sicherheit des Servers ist davon überhaupt nicht betroffen.

Rob
 
Wenn ich die Anwendung ewig einfach machen lasse, weiß ich doch überhaupt nicht mehr, in welchem Status der Code ist. Wenn nur ein einziges Mal jemand durch eine Lücke die Selbstupdate-Funktion manipulieren konnte, habe ich ab da einen potentiellen Dauergast auf dem Server, von dem ich nie was mitkriege. Bis zu dem Zeitpunkt vielleicht, wo local root escalation durch anderweitig entdeckte Lücken möglich wird. Ein weiterer Punkt ist, dass für den meisten Unfug gar kein root nötig ist.

Für Selbstupdates muss man dem WWW-User ja zumindest schonmal ausgehende Verbindungen erlauben und an der Stelle eine weitere Policy managen , wenn man nicht pauschal alles erlauben will. D.h. entweder halte ich diese Policy up-to-date, damit nur Traffic zu den Updateservern funktioniert oder mein Server kann auf einmal andere Server angreifen, super.

Ich halte das alles für grob fahrlässig. Da halte ich doch lieber die Webanwendung für den httpd read-only und kann gleich noch ausgehenden Traffic vom httpd komplett verbieten. Diese zusätzliche Arbeit, den Updatemechanismus noch zu babysitten mit ausgehenden Regeln, steckt man lieber in "manuelle"[1] Updates und hat dafür ein wesentlich besseres Sicherheitskonzept.


[1] manuell im Sinne von "root muss eingreifen", nicht "ich logge mich auf 1000 Servern ein und mache alle Updates zu Fuß".
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben