www-data vs. chroot

[Tanja]

Moin,

gerade versuche ich, User in einem Verzeichnis /srv/chroot_sft/testuser zu chroot-en.
Das klappt bereits sehr gut und dank php-fpm lääst sich auch die Ausführung der PHP Scripts über den Webserver des vhosts mit dem Verzeichnis /srv/chroot_sft/testuser/public_html "einsperren". => php Dateien lassen sich über den Webserver fehlerfrei aufrufen und ausführen.

Nur mit nicht-PHP Dateien habe ich jetzt ein Problem: Alles, was nicht über den PHP Prozess, sondern direkt von nginx "bedient" wird, meldet "Permission denied" als Status und in der error.log.
Der Prozess nginx wird von www-data gehalten.
Mit su www-data und anschließend einem Versuch cat /srv/chroot\_sft/testuser/public\_html/test.js liefert auch "Permission denied".

chmod 777 auf die Datei/en hilft nicht weiter.

Wie kann ich www-data erlauben, grundsätzlich alle Dateien in  /srv/chroot_sft/testuser zu lesen?

Vielen Dank,
Tanja

[Felix Riesterer]

Liebe Tanja,

es ist vielleicht sinnvoll, auf dem Host-System eine Benutzergruppe anzulegen, in der sowohl der Web-Server, als auch der PHP-Prozess (und die jeweiligen FTP-User usw.) enthalten sind.

Wenn dann das Verzeichnis(!) und alle seine Dateien (samt Unterverzeichnisse...) dieser Gruppe zugeordnet sind, dann sollte es keine Berechtigungsprobleme mehr geben.

Liebe Grüße,

Felix Riesterer.

[Tanja]

Hallo Felix,

es ist vielleicht sinnvoll, auf dem Host-System eine Benutzergruppe anzulegen, in der sowohl der Web-Server, als auch der PHP-Prozess (und die jeweiligen FTP-User usw.) enthalten sind.

Der testuser muss der Gruppe sftponly angehören um die Zugriffsbeschränkung hinzubekommen.
Der Benutzer www-data gehört der gleichnamigen Gruppe www-data an.

Wie kann ich diese zusammenbringen oder der Gruppe www-data den Zugriff gewähren.
(Umgekehrt sollte natürlich testuser nicht alle Rechte haben, die www-data hat.)

[Felix Riesterer]

Liebe Tanja,

was hindert Dich denn daran, der Gruppe "sftponly" den Benutzer "www-data" hinzuzufügen?

Liebe Grüße,

Felix Riesterer.

[Tanja]

was hindert Dich denn daran, der Gruppe "sftponly" den Benutzer "www-data" hinzuzufügen?

Das habe ich jetzt gemacht und erhalte weiterhin keinen Lesezugriff für den User www-data.

[dedlfix]

Tach!

Mit su www-data und anschließend einem Versuch cat /srv/chroot\_sft/testuser/public\_html/test.js liefert auch "Permission denied".

Wird wohl stimmen. Schau dir die Besitzverhältnisse und Berechtigungen der Dateien und der Verzeichnisse auf dem Weg dorthin an.

chmod 777 auf die Datei/en hilft nicht weiter.

Bitte nicht immer gleich mit dem Holzhammer probieren. Wenn du nur lesen möchtest, reicht 444 (für Dateien und 555 für Verzeicnisse) vollkommen aus. Die Vorgehensweise, mal pauschal für alle etwas zu erlauben, ist trotzdem unsinnig. Berechtigungen sollten stets zusammen mit den Besitzverhältnisse angeschaut und bewusst gesetzt werden.

Wie kann ich www-data erlauben, grundsätzlich alle Dateien in  /srv/chroot_sft/testuser zu lesen?

Indem du die Berechtigungen für den Pfad und all seine Bestandteile so setzt, dass er das kann.

dedlfix.

[Tanja]

Hallo dedlfix,

/srv/chroot_sft muss root besitzen (sonst klappt das chroot für die Unterverzeichnisse nicht)
/srv/chroot_sft/testuser und Unterverzeichnisse gehören dem testuser (Mitglied der Gruppe sftponly)
/srv/chroot_sft/testuser/public_html würde ich gerne zusätzlich(!) für User oder Gruppe www-data freigeben.

Stehe leider gerade auf dem Schlauch und wüsste gerne, wie ich letzteres hinbekomme.

[Felix Riesterer]

Liebe Tanja,

/srv/chroot_sft muss root besitzen

soweit OK. Aber welcher Benutzergruppe ist dieses Verzeichnis zugewiesen? Es hat ja nicht nur einen Besitzer, sondern gehört ja auch einer Gruppe an... die nicht automatisch auch root sein muss.

/srv/chroot_sft/testuser und Unterverzeichnisse gehören dem testuser (Mitglied der Gruppe sftponly)

Es ist zunächst schön zu wissen, dass der _User_ der Gruppe "sftponly" angehört, aber wie ist das mit dem _Verzeichnis_?

/srv/chroot_sft/testuser/public_html würde ich gerne zusätzlich(!) für User oder Gruppe www-data freigeben.

Dann sollte es einer Gruppe zugewiesen werden, der sowohl testuser als auch www-data angehören. Das könnte z.B. sftponly sein.

Liebe Grüße,

Felix Riesterer.

[Tanja]

/srv/chroot_sft muss root besitzen

soweit OK. Aber welcher Benutzergruppe ist dieses Verzeichnis zugewiesen?

Gruppe: sftponly

/srv/chroot_sft/testuser und Unterverzeichnisse gehören dem testuser (Mitglied der Gruppe sftponly)
Es ist zunächst schön zu wissen, dass der _User_ der Gruppe "sftponly" angehört, aber wie ist das mit dem _Verzeichnis_?

Das gehört dem User testuser und der Gruppe mit dem Namen testuser.

/srv/chroot_sft/testuser/public_html würde ich gerne zusätzlich(!) für User oder Gruppe www-data freigeben.
Dann sollte es einer Gruppe zugewiesen werden, der sowohl testuser als auch www-data angehören. Das könnte z.B. sftponly sein.

OK, so habe ich es jetzt gemacht. /srv/chroot_sft/testuser/public_html -> Gruppe sftponly

Dann noch: useradd -G sftponly www-data

=> immernoch Permission denied für www-data :-(

Müssen denn auch noch alle(?!) übergeordneten Verzeichnisse derselben Gruppe gehören?

[dedlfix]

Tach!

Müssen denn auch noch alle(?!) übergeordneten Verzeichnisse derselben Gruppe gehören?

Nicht zwangsläufig, aber wer in einem Unterverzeichnis was lesen will, muss auch auf irgendeine Weise in allen übergeordneten Verzeichnissen lesen dürfen. Sinnbildlich: Wie willst du ins Büro des Chefs kommen, wenn dir schon der Zutritt zu seiner Etage oder seinem Gebäude verwehrt ist.

dedlfix.

[Tanja]

Update: Nach einem exit und erneuten Aufruf su www-data lassen sich die Dateien im besagten Verzeichnis aufrufen.

Unabhängig von diesem kleinen Erfolg, hilft auch ein Neustart von nginx nicht und der Webserver verweigert weiterhin den Zugriff auf die Dateien.

Sichehreitshalber prüfe ich mit ps aux, ob nginx wirklich von www-data ausgeführt wird => das ist der Fall.

Dann prüfe ich, ob der Webserver im richtigen Verzeichnis nach der richtigen Datei sucht. Die Datei, für die "Permission denied" in der error.log aufgelistet ist, lässt sich von www-data problemlos mit cat dateiname anzeigen. => auch OK.

Und trotzdem Permission denied :-/

[dedlfix]

Tach!

Und trotzdem Permission denied :-/

Du versuchst anscheinend durch Herumstochern zur Lösung zu kommen, anstatt gezielt vorzugehen. Liste bitte von der Datei und all ihren übergeordneten Verzeichnissen Besitzer, Gruppe und Berechtigungen auf sowie die Gruppen vom www-data (id www-data). Du kannst nun auch gern selbst schauen, ob in dieser Liste der www-data oder eine seiner Gruppen Lese-Rechte hat.

Es kann auch sein, dass SELinux noch dazwischenfunkt. sestatus -v sagt dir, ob es enabled ist.

dedlfix.

[dedlfix]

Tach!

Stehe leider gerade auf dem Schlauch und wüsste gerne, wie ich letzteres hinbekomme.

Es scheint mir, dass dir erstmal ein Grundlagentutorial zur Benutzerverwaltung und den Benutzerrechten in Linux/Unix den notwendigen Einblick in die Materie liefern wird.

Hier nur im Groben:

• Ein User gehört immer einer Gruppe an. Zusätzlich können den Gruppen weitere Nutzer zugewiesen werden.
• Dateien und Verzeichnisse ("Datei" steht im nachfolgenden immer für beides) gehören immer einem User und einer Gruppe. Wenn du nun einfach einen User der Gruppe einer Datei zuweist, hat der natürlich auch die der Gruppe gewährten Rechte auf andere Ressourcen. Das ist eventuell nicht gewollt. Notfalls musst du eine dritte Gruppe anlegen, dieser die beiden User zuweisen (als Zusatz, nicht als Hauptgruppe) und die Datei der Gruppe zuweisen.
• Für den Anfang wäre es sinnvoll, wenn du dir die Syntax der Dateien /etc/passwd und /etc/group anschaust.

dedlfix.

[Kay]

Moin,

nur mal so ein Gedanke, ist nginx auch richtig konfiguriert?

Kay

[Kay]

Moin,

Aus: http://wiki.nginx.org/Faq

Is support for chroot planned?
Unknown at this time. Unless/until that changes, you can achieve a similar - or better - effect by using OS-level features (e.g. BSD Jails, OpenVZ w/ proxyarp on Linux, etc.).

Kay