Hallo Freunde,
seit einem der letzten du akzeptiert mein Indianer meine Document Root nicht mehr. Selbst wenn ich in den Verzeichnissen sites-available und sites-enabled alles rausschmeiße außer der default Datei und in diese meinen Pfad zum Webverzeichnis eintrage meldet er mir "You don't have permission to access / on this server." Mit seiner Original-Document-Root meldet er sich sauber mit "It works!"
Ich habe an der Konfiguration nichts geändert und weiß im Moment nicht wo ich suchen soll. Die access.log sagt mir 127.0.0.1 - - [07/Oct/2012:19:04:18 +0200] "GET / HTTP/1.1" 403 492 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:10.0.7) Gecko/20100101 Firefox/10.0.7 Iceweasel/10.0.7"
Kann mir jemand einen Tip geben was geändert wurde oder wo ich suchen soll?
Gruß
Peter
hast du noch ein paar sehr alte kernel installiert, die du booten kannst? Klappt es da?
Schuß ins blaue: das scheint ja ein rechte problem zu sein. Was sich da mit dem 3.5 oder 3.6 kernel geändert hat betrifft setuid. Könnte jedenfalls nicht schaden mal
ls -la /pfad/zu/web-root/
zu zeigen um die rechte zu untersuchen.
Dass es ein Rechte-Problem ist habe ich mir auch schon gedacht und dein Tip mit ls -la brachte mich auf die Idee mein Home-Verzeichnis (dort liegt auch meine Document Root) mal kurzfristig mit den Rechten 777 zu versehen und siehe da es funktioniert. Allerdings finde ich es nicht so prickelnd World den Vollzugriff auf mein Home-Verzeichnis einräumen zu müssen damit der Webserver wieder das Web-Verzeichnis lesen kann. Irgendwo muss sich da was geändert haben denn vorher hatte es mit den Rechten 770 für mein Home-Verzeichnis funktioniert.
Gruß
Peter
Dein Homverzeichnis /home/hpeter braucht mindestens Ausführbarkeitsrechte für Others, also z.B. drwxr-x--x
Danke, funktioniert aber warum hat es vorher ohne funktioniert? Und welchen Sinn soll das haben dass others Ausführbarkeitsrechte auf mein Home-Verzeichnis haben muss? Es müsste doch eigentlich genügen wenn die Nutzer in den richtigen Gruppen eingetragen sind.
bin mir wie schon erwähnt nicht sicher, weil ich das auch nicht voll durchblicke, schaut aber nach setuid änderungen aus. Die handhabung dieses rechte-bits hat sich geändert um missbrauch zu verhindern. Das sorgt(e) dafür, dass bestimmte prozesse nicht mit rechten des ausführenden, sondern mit denen der gruppe des ordners ausgeführt wurden. Und weil sich das geändert hat klappt es nicht mehr ... meine vermutung.
Ja, na klar, es würde auch ausreichend, die Gruppenberechtigungen so zu setzen, dass der Apacheprozess ins jeweilige Homedir gucken kann.
Der Indianer läuft normalerweise unter www-data als Benutzer. und das document root aufs eigene home zu legen ist nicht unbedingt prickelnd. (reine Sicherheitsneurose). Spätestens, wenn follow_symlinks gesetzt ist und directory listings aktiviert, dann kann es witzig aussehen, was der indianer alles ausplappert. :)
Und keine Angst, das ist nicht nur klugscheiß. Das hab ich beim anfänglichen Siduction Hosting auch mal für das ein oder andere Verzeichnis falsch gemacht. kam nicht grade positiv an :)
das problem ist hier ja nicht die frage, *wo* man das document root hinlegt (ich würde es auch nicht ins home legen und directory listings zu deaktivieren ist eingentlich ein *must*) sondern welche änderung den apachen nun dazu gebracht hat vorher funktionierendes nun nicht mehr auszuführen.
Mit meiner setuid idee lag ich wohl eher falsch, weil der apache ja nicht mit rootrechten läuft ...
@ harley-peter
Wie biegst du das document root um, per symlink oder in der apache config?
ich kann einfach das Problem nicht nachvollziehen. Das mag daran liegen, dass meine Indianer am aussterben sind. Da aber alle bisher Überlebenden auf sid laufen und spätestens wöchentlich geupdated wird, kann es eigentlich nich an apache2 liegen.
Das alles natürlich mit der Einschränkung, dass geänderte Konfigurationen in debian mich nicht betreffen, da ich dann doch nicht so mutig bin, die Dinger mit debian-settings zu betreiben.
Eigentlich bleiben nur 2 Sachen über: User und Rechte. Mehr ist da nicht.
Der Apache-Prozess sollte im Standard auf www-data laufen. Um zu funktionieren muss, der Pfad zu den zu browsenden Datein durchgängig Ausführungsrechte für die Directories haben. An sonsten ist keinerlei Zugriff möglich. Einer der "beliebtesten" Fehler bei der Arbeit mit serverdiensten ist das stumpfe setzen von rechten per chmod rekursiv. Das kann und wird mit Anlauf in die Hose gehen. (ausser bei 777, 775, 755, die will man aber nicht wirklich)
Ich bin kein Freund von Welt-Rechten, also betreibe ich meine Server oftmals mit den folgenden Settings
chown user:www-data . -R
find . -type d -exec chmod 750 {} \;
find . -type f -exec chmod 640 {} \;
damit sind im allgemeinen die notwendigen Rechte gesetzt, der apache kann die Directories lesen und ausführen, Daten können gelesen, aber nicht geschrieben werden. Der user hat die selben Rechte, additional aber noch Schreibrechte dazu. Welt bleibt aussen vor. Die davon abweichenden Settings für Rechte und Eigentümer malt man sich zusammen mit den eventuell feineren Granulierungen in ein Script und das wars. Und das funktioniert auch. Bis zum nächsten chmod -R. Deshalb auch das Script. So ein Rechteaufbau über eine Webseite kann manchmal recht filigran werden, wenn man es richtig machen möchte.
DA war noch was, was ich ganz glorreich verschwiegen haben. Das war jetzt nur die Grundkonfiguration der Rechte auf Dateisystem-Ebene. Die Rechte, die innerhalb des Indianers konfiguriert sind, sollen an dieser Stelle mal aussen vor sein. Es gibt im Allgemeinen 3 übliche Stellen, wo geschraubt wird: Die generelle Apache-Konfiguration, irgendwelche Conf.d-Verzeichnisse, die immer mal wieder gerne für Überraschungen sorgen, die virtuellen Hosts an sich und eine Apache-typische Erfindung, die verboten gehört. .htaccess. Die ist im Standard aktiv, wirkt auf Verzeichnisebene, wird in die darunterliegenden Verzeichnisse vererbt und kann dann nur noch innerhalb der jeweiligen Verzeichnisse überschrieben werden. Mit dieser Schwachsinnserfindung kann ich in null-komma-nichts jeden apachen an die Wand fahren.
Da aber in diesem Fall das einfache Setzen der Dateirechte ausgereicht hat, gehe ich mal nicht davon aus, dass an dieser Stelle was schief gegangen ist.
Quote from: "agaida"...
Ich bin kein Freund von Welt-Rechten, also betreibe ich meine Server oftmals mit den folgenden Settings
chown user:www-data . -R
find . -type d -exec chmod 750 {} \;
find . -type f -exec chmod 640 {} \;
...Welt bleibt aussen vor. ...
(ich weiß nicht ob wir beginnen uns hier OT zu verirren, ich mach trotzdem mal weiter:)
Und wie soll Otto Mustermann etwas von diesem webserver sehen können?
ich hoffe doch, gar nicht ... Aber im Ernst:
Die Kommunikation mit der Aussenwelt übernimmt der Serverdienst. Der hat einen Benutzer (www-data) und kann auf das Dateisystem zugreifen. Welt braucht bei einem ordentlich konfigurierten Server keinen Zugriff auf die Dateien, wenn Eigentums- und Zugriffsrechte ordentlich gesetzt sind. Der Denkfehler bei Dir ist, dass Du unbewusst auf lokale Rechte abstellst.
Hallo Freunde,
erst mal vielen Dank für die Hilfe und die vielen Tips.
Das Sicherheitsproblem ist erst mal nicht im Vordergrund da der Apache in diesem Fall nur lokal für eine Entwicklungsumgebung läuft und deshalb habe ich die Document Root aus Bequemlichkeit ins Home-Verzeichnis verschoben.
@michaa7: Ich habe das mit einem Symlink in sites-enabled gemacht der auf die entsprechende Datei in sites-available zeigt. Allerdings funktioniert das seit Neuestem nur noch wenn ich die geänderte Document Root direkt in die default-Datei eintrage, meine selbsterstellten Kopien der default (um nicht an der default-Datei herumzuschrauben) ignoriert der Apache jetzt ebenfalls. Hat früher auch funktioniert.
@agaida: Wenn deine Indianer am aussterben sind welchen Webserver benutzt du denn und was ist der Vorteil gegenüber Apache?
@agaida
Danke für deine erklärung, ich daachte mir schon soetwas, bin aber dennoch verwirrt: Wenn ich mit meinem browser auf 127.0.0.1 zugreife klappt das nur, wenn es world ausführbar ist. Heißt das, dass die rechteauswertung lokal (127.0.0.1) anders verläuft als aus der ferne? Da habe ich in der tat einen knoten im hirn, über dessen lösung ich sehr froh wäre.
@ harley-peter
der *symlink* gehört, glaube ich, per default (?) root, und soweit du dies für den symlink nicht geändert hast greift vielleicht doch meine setuid-vermutung.
Andererseits, die beschriebenen problem min den dateikopien lassen dann doch auch änderungen am apache selbst vermuten, auch hier solltest du mal die rechte vergleichen. Dennoch, irgendwie verdächtige ich die symlinks ...
@ harley-peter
Ich benutze apache2 nur noch, wenn ich zu blöd und/oder faul bin, die redirects umzuschreiben. Ansonsten bin ich bei nginx gelandet. Die Sachen, die damit zu verkonfigurieren sind, sind wesentlich weniger - und das Teil ist robust und rattenschnell.
debian mag nginx nicht so sehr, weil man ihn selbst mit den gewählten Features kompilieren muss und empfielt lighty.
@michaa7
Kein Problem, das mit dem Knoten kenne ich, das hebelt mich regelmäßig aus. Du haust da nur ein paar Sachen durcheinander, die so nicht miteinander verdrahtet sind. Der Trick ist immer die Auftrennung in Ebenen und die Frage, wer was zu welcher Zeit macht und dazu welche Rechte benötigt. Wenn Du lokal Welt-Rechte benötigst, damit Dein Server-Prozess die Dateien lesen kann, dann hat der Serverprozess die falschen Rechte, kann also als www-data nicht auf die Dateien zugreifen. Das ist sehr einfach zu kontrollieren:
su
su www-data
ls /path/to/your/datas
cat /path/to/your/datas/$file
Geht das schief, dann scheitert der Serverprozess genauso.
@michaa7
Die Rechte von den Symlinks habe ich nicht geändert. Sie gehören natürlich root und haben die Rechte 777. Da ich nur eine Kopie von der vom System eingerichteten default-Datei benutze haben meine Dateien dieselben Rechte. Die Original-Dateien in sites-available haben die Rechte 644.
@agaida
Danke für den Tip, werde mir mal nginx anschauen.
Ich versuche auch deinem Dialog mit michaa7 zu folgen. Wenn du sagst der Serverprozess hat die falschen Rechte und kann deshalb auf die Dateien nicht zugreifen wie kann ich denn diese Rechte ändern?
die Frage ist doch erst mal: kannst Du so, wie von mir aufgemalt, als www-data auf die Daten zugreifen? Wenn nicht, was sagt ein id www-data?
EDIT: Ohne Dir zu nahe zu treten zu wollen: nginx ist zwar geil, aber für Fortgeschrittene. D.h. die Chance, sich damit ins Knie zu schießen ist recht hoch, da nicht gar so viel vernünftige Hauzus existieren. Eventuell ist da light-httpd besser, den können von uns mehr Leute supporten.
Jo, ich kann problemlos auf die Daten zugreifen, keinerlei Fehlermeldung.
Und ein id www-data sagt:
root@master:/home/peter# id www-data
uid=33(www-data) gid=33(www-data) Gruppen=33(www-data)
Du trittst mir nicht zu nahe ganz im Gegenteil: mir ist viel lieber mir sagt einer "lass die Finger davon da fehlt dir das Wissen" als dass er mich ins offene Messer laufen lässt.