chmod 777 auf web/?!?

[EL Duderino]

Beim herumspielen habe ich gerade gesehen, dass die Rechte für meinen web-Ordner (und auch andere in /volume1) auf

drwxrwxrwx    8 root     root

eingestellt sind. Das kann doch nicht sein, oder bedenke ich etwas nicht richtig?

 

[jahlives]

ist zwar nicht besonders schön, aber solange der Eigentümer und die Gruppe root ist muss others Schreibrechte haben, weil sonst der Webserver (nobody) nicht schreiben dürfte

 

[EL Duderino]

ist zwar nicht besonders schön, aber solange der Eigentümer und die Gruppe root ist muss others Schreibrechte haben, weil sonst der Webserver (nobody) nicht schreiben dürfte

Das nobody darauf schreiben darf, ist für mich das Seltsame. Ganz merkwürdig finde ich es, wenn Verzeichnisse in /volume1/web nobody als Besitzer haben. Das ist bei Owncloud aus dem CPH und bei selbstinstalliertem TT-RSS nach einem Selbstupdate so. Erscheint mir nicht so günstig, da nobody diese Verzeichnisse auch Löschen könnte. Oder schätze ich diese Gefahren völlig falsch ein - und sollte an ganz andere Gefahren denken, die ein gekaperter Apache unter nobody verursachen könnte?

 

[jahlives]

Wie willst du denn z.B. Dateien vom Browser hochladen, wenn nobody nicht zumindest auf bestimmte Verzeichnisse schreiben darf? Viele Websachen erfordern, dass der Webserver in bestimmte Verzeichnisse schreiben darf. Du kannst das aber auch via Kommandozeile anpassen und z.B. den nobody nur noch dort zum Eigentümer machen wo auch wirklich seitens des Webservers geschrieben werden können muss. imho ist es aber besser den nobody an den nötigen Stellen zum Eigentümer zu machen als einfach chmod 0777 drüber zu jagen. Denn als nobody kann man sich nicht einloggen von dem her ist das besser geschützt als ein chmod 0777

 

[joku]

die ein gekaperter Apache unter nobody verursachen könnte?

Hallo, ob der Apche nobody, wwwrun oder sonst wie heißt, schreiben darf er da immer Gruß Jo

 

[EL Duderino]

Wie willst du denn z.B. Dateien vom Browser hochladen, wenn nobody nicht zumindest auf bestimmte Verzeichnisse schreiben darf? Viele Websachen erfordern, dass der Webserver in bestimmte Verzeichnisse schreiben darf.

Das ist klar, frage ich unter noch mal gewohnt detailliert ab . Aber wie ist das mit /volume1/web? Habe festgestellt, daß das Selbstupdate von ttrss mit 755 darauf nicht mehr funktioniert (trss benennt sein altes Verzeichnis um und erstellt ein neues, dafür braucht nobody Schreibrechte). Das kann ich von Hand freischalten, aber was zum Beispiel verliere ich dadurch noch/geht damit nicht mehr?

Generell gefragt: mache ich mir zu viele Gedanken und sollte, wenn ich auf Sicherheit Wert lege, lieber strikt auftrennen zwischen Webservices und dem Rest (2. Maschine)?

Du kannst das aber auch via Kommandozeile anpassen und z.B. den nobody nur noch dort zum Eigentümer machen wo auch wirklich seitens des Webservers geschrieben werden können muss. Du kannst das aber auch via Kommandozeile anpassen und z.B. den nobody nur noch dort zum Eigentümer machen wo auch wirklich seitens des Webservers geschrieben werden können muss.

OK. Zum Beispiel ist mir bekannt, daß ttrss nur in bestimmte cache-Unterverzeichnisse schreiben will, und sonst alles in die Datenbank schreibt. Wäre es dann angemessener, die Datei in der das MySQL-Passwort steht, mit

chown nobody:nobody config.php
chmod 700 config.php

(oder sogar 300?) zu verriegeln, den Rest (außer dem Cache) aber unter root:root mit Modus 755 (für nobody (und alle) les-, aber nicht schreibbar) zu haben?

Bei owncloud habe ich sqllite als Backend, diese Dateien müssen also für nobody schreibbar sein, aber wie ist das mit dem Rest? Kann man generell sagen

root:root 700 > root:root 755, nobody:nobody 700 > nobody:nobody 755 > root:root 777

und zwischen "root:root 755" und "nobody:nobody 700" kommt es drauf an?

P.S.

imho ist es aber besser den nobody an den nötigen Stellen zum Eigentümer zu machen als einfach chmod 0777 drüber zu jagen. Denn als nobody kann man sich nicht einloggen von dem her ist das besser geschützt als ein chmod 0777

Wenn wir gerade darüber reden, daß sich nobody nicht einloggen kann: Ich habe da ein Problem beim Booten.