Kein www-data -> weltweite Schreibrechte für alle?

[Janis]

Hatte heute ein frustrierendes Gespräch mit einem 1und1-Mitarbeiter. Der kannte sich leider mit Dateirechten unter Linux weniger aus als ich.

Die Situation:
Benutzer können über meine mit Contao erstellte Seite Bilder in das Verzeichnis images upladen.

So sieht das lokal auf meinem Testrechner aus:

drwxrwx--- www-data www-data images
rw-rw---- www-data www-data Foto.jpg

Übertrage ich das per SFTP nach 1und1, ändern sich Rechte und der Gruppenname:

drwx---r-x p99999999 ftpusers images
rw-rw---- p99999999 ftpusers Foto.jpg

Owner (p99999999) hat sich geändert, das ist ok.
Problem 1: Gruppe hat sich geändert (ftpusers), nicht ok - aber auch per ssh lässt sich das nicht auf www-data ändern.
Problem 2: Beim Verzeichnis fallen die Gruppenrechte weg und jetzt erhalten "others" Rechte.
Problem 3: Das Foto kann über den Webbrowser nicht mehr aufgerufen werden.

Setze ich die Rechte für das Foto auf
chmod 606 Foto.jpg
zeigt der Browser dieses an und ein Benutzer könnte es über Contao auch wieder löschen ... aber ist das nicht viel zu gefährlich, wenn "others", also alle, die irgendwie auf den Webspace gelangen, Schreibrechte haben?

Wer erhellt mich? :-)

[Janis]

Ich habe heute heftig weiter-gegoogelt, bekomme aber keine Klarheit zu obigen Fragen.
Eins habe ich nocht gefunden, PHP läuft bei 1und1 als FastCGI und nicht als php_mod.

Hoffe, jemand hier kann Klarheit schaffen.

Gut's Nächtle
Janis

[tab]

Also es ist schon so, dass 1&1 mit den Dateirechten ein anderes Konzept fährt als die meisten anderen Hoster. Insbesondere die Gruppe hat gar keine Rechte, dafür "others" auch Schreibrechte. Im Detail stecke ich da auch nicht drin, es gibt hier im Forum aber irgendwo einen Beitrag, der zumindest Ansätze erklärt. Jedenfalls basiert das Konzept wohl unter anderem darauf, dass alle User auf dem jeweiligen Server zur selben Gruppe gehören.

Deswegen auch die nicht vorhandenen Gruppenrechte. Sonst könnten alle anderen User auf deinem Server auf deine Daten zugreifen und du auf ihre, was nicht besonders sinnvoll wäre. Deswegen ist natürlich auch klar, dass deine lokalen Rechteeinstellungen nicht so einfach übernommen werden können. Könntest du deinem User eine andere Gruppe zuweisen, dann hättest du Rechte auf allen Datein der anderen User, weil du nicht mehr in ihrer Gruppe wärst. Würden deine Dateien einer anderen Gruppe gehören als vom Sytem vorgegeben, dann hätten andere User Zugriffsrechte auf deine Dateien.

[Janis]

Danke, das erhellt tatsächlich und deckt sich weitestgehend mit meinen praktischen Beobachtungen. Zum Verständnis noch zwei Anmerkungen/Fragen, s.u.

Also es ist schon so, dass 1&1 mit den Dateirechten ein anderes Konzept fährt als die meisten anderen Hoster. Insbesondere die Gruppe hat gar keine Rechte, dafür "others" auch Schreibrechte. Im Detail stecke ich da auch nicht drin, es gibt hier im Forum aber irgendwo einen Beitrag, der zumindest Ansätze erklärt. Jedenfalls basiert das Konzept wohl unter anderem darauf, dass alle User auf dem jeweiligen Server zur selben Gruppe gehören.

DIe Gruppe heißt "ftpusers".

Also es ist schon so, dass 1&1 mit den Dateirechten ein anderes Konzept fährt als die meisten anderen Hoster. Insbesondere die Gruppe hat gar keine Rechte, dafür "others" auch Schreibrechte.

So verstehe ich das Konzept:
1. Wenn die Gruppe (ftpusers) gar keine Rechte, "others" aber Schreibrechte hat, so hat darüber doch jeder User Schreibrechte. Und wenn er sich auf dem selben Server befindet, kann er dann auch wirklich schreiben. Das ist ja mordsgefährlich!

2. Nach dem "1und1-Konzept" besteht dann aber doch zwischen folgenden beiden Dateirechten kein Unterschied:
rw----rw- p99999999 ftpusers Foto.jpg
rw-rw-rw- p99999999 ftpusers Foto.jpg

3. Wenn "others" keine Schreibrechte haben soll, darf nach dem "1und1-Konzept" die Gruppe "ftpusers" natürlich ebenfalls keine Schreibrechte haben. So etwas sollte man tunlichst sein lassen:
rw-rw-r-- p99999999 ftpusers Foto.jpg
Da es keinen Grund für die meisten gibt, dass ein anderer 1und1-Kunde auf dem gleichen Server in unsere Verzeichnisse pfuscht, bringen uns Gruppenrechte für "ftpusers" keine Vorteile sondern nur Nachteile. Ist also folgendes problemlos möglich und empfehlenswert?

EInloggen per ssh und dann Gruppe "ftpusers" alle Rechte entziehen:
chmod -R g-rwx ~

[tab]

So verstehe ich das Konzept:
1. Wenn die Gruppe (ftpusers) gar keine Rechte, "others" aber Schreibrechte hat, so hat darüber doch jeder User Schreibrechte. Und wenn er sich auf dem selben Server befindet, kann er dann auch wirklich schreiben. Das ist ja mordsgefährlich!

Nicht wirklich. Ein Mitglied der Gruppe ist kein "Sonstiger". Die Rechte für "others" gelten nur für Benutzer, die nicht zur Gruppe ftpusers gehören. Also z.B. vermutlich Systemprogramme oder auch der Apache. Solange also sichergestellt ist, dass alle Kunden, die auf dem selben Server sind, zu dieser Gruppe ftpusers gehören, haben sie keine Datei oder Verzeichnisrechte auf deinem Webspace. Ausnahme: du selbst als owner, aber nur, wenn der Owner auch Zugriffsrechte hat, was hier natürlich der Fall ist. Kannst ja aber mal folgendes probieren:
Gib einer Textdatei (z.B. test.txt) mal mit "chmod 066 test.txt" und versuche dann z.B. mit "cat test.txt" darauf zuzugreifen. Geht nicht...
cat: test.txt: Permission denied
Du als Owner hast die dazu notwendigen Rechte nicht!

[Janis]

Gib einer Textdatei (z.B. test.txt) mal mit "chmod 066 test.txt" und versuche dann z.B. mit "cat test.txt" darauf zuzugreifen. Geht nicht...
cat: test.txt: Permission denied
Du als Owner hast die dazu notwendigen Rechte nicht!

Hab's gemacht, auch mal mit 006. Ist so wie Du sagst - arbeite seit Jahren intensiv mit Linux, das war mir nie aufgefallen.

Solange also sichergestellt ist, dass alle Kunden, die auf dem selben Server sind, zu dieser Gruppe ftpusers gehören, haben sie keine Datei oder Verzeichnisrechte auf deinem Webspace.

Wenn für eine Datei folgende Rechte vergeben sind,
rw-rw-r--
dann hat die Gruppe ftpuser doch Dateirechte, und zwar "rw". (?)

Das spricht doch dafür entsprechend meiner Anmerkung (3) oben folgendens zu machen:

EInloggen per ssh und dann Gruppe "ftpusers" alle Rechte entziehen:
chmod -R g-rwx ~

Möglicherweise hast Du das auch so gemeint? Ich möchte den Thread nur nicht beenden und dabei etwas für Folgeleser im Unklaren oder halbrichtig stehen lassen.

[tab]

Der Gruppe ftpusers alle Rechte zu entziehen ist zu 99,9% unschädlich, für Contao werden diese Rechte nicht gebraucht. Ob es nötig ist, ist eine andere Frage, weil ich mal zugunsten der 1&1 Systemadmins davon ausgehe, dass sie durch fehlende Gruppenechte in übergeordneten Verzeichnissen sicherstellen, dass ich - obwohl ich als Angehöriger der Gruppe ftpuser für eine konkrete Datei die Rechte dazu hätte - wegen der fehlenden Verzeichnisrechte keinen Zugriff auf die Datei habe. Trotzdem, ohne diese Gruppenrechte schläft es sich wohl besser. Und ob das alles wirklich 100% wasserdicht konfiguriert ist, dafür würde ich jetzt nicht die Hand ins Feuer legen. Bei keinem Hoster. Habe bei mir auch noch ein paar alte Verzeichnisse und Dateien mit Gruppenrechten gefunden.

Hast du diese Gruppenrechte selbst gesetzt oder sind das eventuell noch ältere Dateien? Neue Dateien werden gemäß der aktuell defaultmäßig gesetzten umask von 0072 ohne Rechte für die Gruppe angelegt. Früher war dieser Wert 0022, also durfte die Gruppe lesen und ggf ausführen - soweit sie es wegen der Verzeichnisrechte überhaupt konnte. Kannst dir ja mal per SSH die Rechte der übergeordneten Verzeichnisse anschauen. Es wurde dann wohl geändert, weil alle Kunden sich das /tmp teilen, siehe auch hier.

[Janis]

Der Gruppe ftpusers alle Rechte zu entziehen ist zu 99,9% unschädlich

Ich nehme an, die fehlenden 0,01% sind Deinem Wissenstand geschuldet und nicht der Tatsache, dass Du von einem konkreten Problem Kenntnis hast.

Hast du diese Gruppenrechte selbst gesetzt oder sind das eventuell noch ältere Dateien?

Sind ältere Dateien.

Und hier für Leute, die sich ebenfalls mit den Gruppenrechten beschäftigen einige Befehle, die ich mir gerade zusammengestellt habe:

Suchen wo die "group" mehr Rechte als "others" hat:

find -exec ls -l {} \; | grep -E "^....(r..-..|.w..-.|..x..-)"

Suchen, wo "group" irgendein Recht hat, also alles außer "---":

find -exec ls -l {} \; | grep -E "^[-]...(rwx|rw-|r-x|r--|-wx|-w-|--x)"

"group" sämtliche Rechte entziehen:

chmod g-rwx ~

[tab]

Ich nehme an, die fehlenden 0,01% sind Deinem Wissenstand geschuldet und nicht der Tatsache, dass Du von einem konkreten Problem Kenntnis hast.

Ja, konkrete Probleme, die irgendeiner hier wegen dieser Rechte geschrieben hätte, sind mir nicht bekannt. Lediglich, dass der Contao-Check wegen dieser speziellen Rechte meckert und meint, man müsse den Safe Mode Hack benutzen und könne auch Composer wegen des SMH nicht benutzen. Beides stimmt nicht und kann ignoriert werden. Es ist kein Safe Mode Hack notwendig und somit kann auch Composer genutzt werden, soweit es das verfügbare RAM zulässt .

[Thomas]

Das trägt jetzt nicht wirklich zu dem Thema bei, aber das bestätigt mal wieder, dass man sich nicht für 1und1 entscheiden sollte und lieber auf Qualität als Quantität setzen sollte.

[Janis]

Das trägt jetzt nicht wirklich zu dem Thema bei, aber das bestätigt mal wieder, dass man sich nicht für 1und1 entscheiden sollte und lieber auf Qualität als Quantität setzen sollte.

Tut mir leid, für diesen qualifizierten Beitrag kann ich leider weder das "Like" geben noch einen der Wünsche von der Wunschliste erfüllen. :-(
Trifft weder das Thema noch bestätigt das irgendwas pauschal.