Webserver mit nginx, zugriff auf Logfiles nicht möglich

[KodaC]

Hallo Zusammen

erstmal allen ein frohes und gesundes 2018.

Ich habe mich auf einer VM mal etwas an einen nginx Webserver gewagt diesen aufzubauen.
Es gibt einen Benutzer Tim, welcher in der Gruppe www-data ist.
Wenn der Benutzer in seinem www verzeichnis eine Datei erstellt haben diese die rechte Tim:Tim
Das funktioniert alles ohne jegliche Probleme.

Die Logfiles haben jedoch die Rechte www-data:www-data
-rwxr-x--- 1 www-data www-data 30127 Dez 13 05:57 access.log

Gibt es eine Möglichkeit dem Benutzer Tim die Rechte für die Dateien (lesen) zu geben, ohne ihm gleich ssh rechte geben zu müssen, und ohne per crontab die Logs all paar Minuten die Berechtigungen anzupassen? Ggf gibt es auch in der vhost für nginx die möglichkeit zu sagen für welchen Benutzer die Logs erstellt werden?

Gruss und Danke

Koda

[MSfree]

Es gibt einen Benutzer Tim, welcher in der Gruppe www-data ist.

Die Logfiles haben jedoch die Rechte www-data:www-data
-rwxr-x--- 1 www-data www-data 30127 Dez 13 05:57 access.log

1. Fehler:
Wer hat den Logfiles diese gefährliche Berechtigung verpaßt? Einfache Textdateien dürfen niemals ausführbar sein! Bitte ändere das umgehend. Dateien, die nicht ausführbar zu sein brauchen, muß man aus Sicherheitsgründen auch nicht ausführbar lassen.

2. Denkfehler:
Wenn der User Tim in der Grupppe www-data ist, darf er die Datei auch ansehen. Hier ist also nur nochmal zu prüfen, ob Tim wirklich in der Gruppe ist:
- einloggen als Tim
- auf der Kommandozeile id eingeben
- in der Ausgabe prüfen ob www-data dort auftaucht.
- der einzige Grund, der Tim dann noch einen Zugriff auf die Log-Datei versperrt, ist, wenn das Verzeichnis, in dem die Datei steckt, keine Lese+Execute-Rechte für www-data hat (ja, Verzeichnisse müssen, im Gegensatz zu Dateien, ausführbar sein.)

3. Denkfehler:
Mit „SSH-Rechte“ gibt es auf Linux nicht. Grundsätzlich darf jeder normale User SSH ausführen.

[KodaC]

Vielen Dank für deine ausführlichen Antworten.

1. Fehler:
Wer hat den Logfiles diese gefährliche Berechtigung verpaßt? Einfache Textdateien dürfen niemals ausführbar sein! Bitte ändere das umgehend. Dateien, die nicht ausführbar zu sein brauchen, muß man aus Sicherheitsgründen auch nicht ausführbar lassen.

Dies stammt aus einem Tutorial. Dort hiess es beim erstellen der vHost die entsprechenden Logverzeichnisse erstellen, und dem Verzeichnis die chmod 770 geben. Genau wie dem Ordner session. Was wäre denn besser? Ich nehme an wegen dem Ordnerrecht werden die Dateien entsprechend so gesetzt oder? Ansonsten müsse es wohl irgend eine nginx einstellung sein.
EDIT. Auch in diesem Installationsscript wird 770 verwendet, für die sessions aber nur 700 https://github.com/miteshashar/nginx_vh ... tup.sh#L97

2. Denkfehler:
Wenn der User Tim in der Grupppe www-data ist, darf er die Datei auch ansehen. Hier ist also nur nochmal zu prüfen, ob Tim wirklich in der Gruppe ist:
- einloggen als Tim
- auf der Kommandozeile id eingeben
- in der Ausgabe prüfen ob www-data dort auftaucht.
- der einzige Grund, der Tim dann noch einen Zugriff auf die Log-Datei versperrt, ist, wenn das Verzeichnis, in dem die Datei steckt, keine Lese+Execute-Rechte für www-data hat (ja, Verzeichnisse müssen, im Gegensatz zu Dateien, ausführbar sein.)

Der Benutzer tim hat keinen ssh zugang. Als root id Tim und auf www-data ergibt folgendes:

Code: Alles auswählen

id Tim
uid=1001(Tim) gid=1001(Tim) Gruppen=1001(Tim)

id www-data
uid=33(www-data) gid=33(www-data) Gruppen=33(www-data),1001(Tim),999(gitlab-www)

3. Denkfehler:
Mit „SSH-Rechte“ gibt es auf Linux nicht. Grundsätzlich darf jeder normale User SSH ausführen.

Ok dann habe ich einen englischen Artikel falsch vertanden

[MSfree]

Dies stammt aus einem Tutorial. Dort hiess es beim erstellen der vHost die entsprechenden Logverzeichnisse erstellen, und dem Verzeichnis die chmod 770 geben.

Richtig, dem Verzeichnis soll man mit chmod 770, besser wäre hier aber chmod 750, die entsprechenden Rechte geben. Dort stand aber bestimmt nicht, daß man den Dateien in eben diesem Verzeichnis ebenfalls mit chmod 770 diese Rechte verpassen soll. Du hast wahrscheinlich auch nicht chmod 770 sondern chmod -R 770 verwende, was dann eben dazu führt, daß alle Dateien und Verzeichnisse unterhalb des angegebenen Verzeichnisses rekursiv gechmodet werden. Von dem Rekursivparameter -R sollte man bei chmod lieber die Finger lassen, der führt praktisch unweigerlich zu ungewollten Nebenwirkungen.

Warum ich so auf dem Execute-Flag von Dateien rumreite?
Ganz einfach, vor allem die Logs von Webservern beinhalten (je nach Loglevel) praktisch alle Interaktionen, die von aussen dem Webserver gestellt werden. Mit einem Adressaufruf über einen Browser ließe sich theroretisch auch die Zeichenkette

Code: Alles auswählen

rm -rf /

in das Logfile einschleusen. Wenn dann die Logdatei auch noch praktischerwise ausführbar ist, ist der Angriffsvektor, das System zu zerstören relativ kurz, der passende Befehl steht ja schon in einer ausführbaren Datei.

Ich nehme an wegen dem Ordnerrecht werden die Dateien entsprechend so gesetzt oder?

Nein, dafür ist nur die umaks des Benutzers zuständig, die auch gerne mal aus falscher "Bequemlichkeit" auf 0000 gesetzt wird.

https://github.com/miteshashar/nginx_vh ... tup.sh#L97

Nunja, das Skript ansich birgt gerade bei den chmods ein paar Stolperfallen, die ich als gefährlich bezeichnen würde.

Der Benutzer tim hat keinen ssh zugang. Als root id Tim und auf www-data ergibt folgendes:

Code: Alles auswählen

id Tim
uid=1001(Tim) gid=1001(Tim) Gruppen=1001(Tim)

id www-data
uid=33(www-data) gid=33(www-data) Gruppen=33(www-data),1001(Tim),999(gitlab-www)

Wie du siehst, gehört Tim nicht zur Gruppe www-data, also darf er Dateien, die leseberechtigt für Mitglieder der Gruppe www-data sind, auch nicht lesen, eigentlich doch ganz logisch.

Code: Alles auswählen

usermod -G www-data Tim

sollte das beheben.

[KodaC]

Vielen Dank. Das Hilft weiter, jedoch habe ich neue Probkeme damit

Richtig, dem Verzeichnis soll man mit chmod 770, besser wäre hier aber chmod 750, die entsprechenden Rechte geben. Dort stand aber bestimmt nicht, daß man den Dateien in eben diesem Verzeichnis ebenfalls mit chmod 770 diese Rechte verpassen soll. Du hast wahrscheinlich auch nicht chmod 770 sondern chmod -R 770 verwende, was dann eben dazu führt, daß alle Dateien und Verzeichnisse unterhalb des angegebenen Verzeichnisses rekursiv gechmodet werden. Von dem Rekursivparameter -R sollte man bei chmod lieber die Finger lassen, der führt praktisch unweigerlich zu ungewollten Nebenwirkungen.

Nicht ganz aber fast.
Logs: /var/www/tim/logs
Nach einer Anleitung habe ich chmod 750 -R /var/www/tim verwendet. Ich werde dies somit nicht auf den Ordner tim sondern auf tim/html/ setzen. Dann msste es passen oder?
Ich bin froh wenn jemand auf sowas rumreitet, denn nur dann kann ich daraus lernen und es nun per sofort besser machen. Danke.

Ich habe deinen usermod verwendet. Nun habe ich zugriff. Aber was ich mich frage:
1. Ich habe usermod -aG tim www-data ausgeführt. Dies habe ich in diversen Tutorials und auch hier wieder gefunden: https://github.com/miteshashar/nginx_vh ... tup.sh#L85. Ich nehme an, -aG ist ok, aber die Namen/Gruppe sind vertauscht?

2. Nun habe ich keinen Zugriff mehr aus SFTP, was vor dem Befehl geklappt hat. Ausschnitt aus der sshd_config:

Code: Alles auswählen

Subsystem sftp internal-s
# This section must be placed at the very end of sshd_config
Match Group www-data
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

SIehst du da ein Fehler? Die Gruppe müsste doch gehen?

Fehler:

Code: Alles auswählen

[15:52:05] [R] Hostschlüssel-Algorithmus ecdsa-sha2-nistp256, Größe 192 Bits.
[15:52:05] [R] Fingerabdruck (SHA256): .........
[15:52:05] [R] Schlüsselaustausch: ........... Sitzungsverschlüsselung: aes256-gcm@openssh.com, MAC: <implicit>, Kompression: none.
[15:52:07] [R] Auth Type: Password
[15:52:07] [R] Authentifizierung erfolgreich
[15:52:07] [R] SSH Verbindung offen
[15:52:07] [R] Netzwerkfehler (10054): Verbindung durch Peer zurückgesetzt
[15:52:07] [R] SFTP-Verbindung bereit
[15:52:07] [R] Verbindung fehlgeschlagen

[MSfree]

Nach einer Anleitung habe ich chmod 750 -R /var/www/tim verwendet. Ich werde dies somit nicht auf den Ordner tim sondern auf tim/html/ setzen. Dann msste es passen oder?

Wie gesagt, laß "-R" bei chmod lieber weg.

Wenn du dem Ordner /var/www/tim/html den Berechtigungscode 750 geben willst, dann mach das mit

Code: Alles auswählen

chmod 750 /var/www/tim/html

1. Ich habe usermod -aG tim www-data ausgeführt. Dies habe ich in diversen Tutorials und auch hier wieder gefunden: https://github.com/miteshashar/nginx_vh ... tup.sh#L85. Ich nehme an, -aG ist ok, aber die Namen/Gruppe sind vertauscht?

Ich meine, und das sagt eigentlich auch die Anleitung, die man mit man usermod auf der Konsole selbst aufrufen kann, daß es usermod -aG www-data tim heißen muß.

Du hast mit deinem Befehl den user www-data der Benutzergruppe tim zugefügt, mit entpsrechenden Nebenwirkungen, z.B. funktioniert sftp nicht mehr. Es ist ziemlich verwirrend, daß es für jeden angelegten User auch eine glaichnamige Gruppe gibt. Für den User tim gibt es eine Gruppe tim, in der der User tim Mitglied ist und ditto für www-data.

Die falsch gesetze Gruppenzuordnung kannst du durch

Code: Alles auswählen

usermod -G tim www-data

reparieren.

Prüfe hinterher aber nochmal nach, ob id tim und id www-data nun den richtigen Gruppen zugeordnet sind.

Im Prinzip kann man statt der ganzen usermod-Prozeduren auch direkt die Datei /etc/group editieren, das Format ist ziemlich selbsterklärend.

[KodaC]

Vielen Dank.

Hast du noch eine Idee wie ich den SFTP wieder zum laufen bekomme?

Wenn ich usermod -g tim tim mache, so komme ich wieder auf den SFTP. Sobald ich tim wieder in die www-data lege damit ich die logs lesen kann, geht die SFTP Verbindung nicht.

Sobald ich das auskommentiere:

Code: Alles auswählen

Match Group www-data
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

geht die Verbindung wenn Tim in der Gruppe www-data ist, er ist jedoch nicht in seinem Homeverzeichnis gefangen.

EDIT: Nach dem ich dem Homeverzeichnis des Benutzers TIM chown root:root und chmod 750 gegeben habe ging es. ich setze mal das system neu auf und teste neu

Gruss

Koda

[MSfree]

Wenn ich usermod -g tim tim mache, so komme ich wieder auf den SFTP.

Warum führt du denn hier usermod -g tim tim aus?
Mir scheint, du nimmst alle möglichen Befehle aus dem Netz und probierst völig unwissend damit herum, ohne überhaupt verstanden zu haben, was sie bewirken.

Bitte führe

Code: Alles auswählen

man usermod

aus!

Der einzige Grund, warum dein sftp nicht mehr läuft, war dein oben falsch ausgeführter usermod-Befehl:

1. Ich habe usermod -aG tim www-data ausgeführt. Dies habe ich in diversen Tutorials und auch hier wieder gefunden: https://github.com/miteshashar/nginx_vh ... tup.sh#L85. Ich nehme an, -aG ist ok, aber die Namen/Gruppe sind vertauscht?

Der hätte usermod -aG www-data tim lauten müssen. Wie du diesen einen kleinen Fehler hättest rückgängig machen können, hatte ich ja bereits geschrieben. Da ich inzwischen nicht mehr weiß, welchen Unsinn du sonst noch angestellt hast, fangen wir halt nochmal von vorne an:
Wie lauten die Ausgaben von

Code: Alles auswählen

id tim
id www-data

von deinem aktuellen Zustand?

Sobald ich tim wieder in die www-data lege damit ich die logs lesen kann, geht die SFTP Verbindung nicht.

Logisch!
Deine Benutzer-zu-Gruppen-Zuordnung ist gründlich durcheinander.

Sobald ich das auskommentiere:

Code: Alles auswählen

Match Group www-data
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

Alles gut, alles korrekt, bloß nicht ändern!

Mit deinem Problem hat dieser Eintrag überhaupt nichts zu tun.

[KodaC]

Vielen Dank für dein Problem.

Ich habe nun alles neu gemacht damit ich auch verstehe wo was schief gegangen ist. Vielen Dank nochmals für deine Hilfe.

Ich hatte drei Grundlegende Probleme:
1. Die Benutzerrechte, bei dem ich Benutzername und Gruppe vertauscht habe
2. CHMOD Rechte 750 anstelle 755 auf dem Heimverzeichnis des Benutzers
3. Das Heimverzeichnis des Benutzers hatte die rechte Tim:www-data anstelle root:root

Nach der Neuinstallation und nach dem ich alles so einrichtet habe geht es. Auch die Logfile rechte sind nun angepasst:
-rw-r--r-- 1 root root 0 Jan 2 08:51 access.log
-rw-r--r-- 1 root root 0 Jan 2 08:51 error.log

Ich finde es zwar etwas speziell das die Dateirechte nun auf root:root sind, aber Tim hat sauber zugriff darauf.

Code: Alles auswählen

id Tim
uid=1001(Tim) gid=1001(Tim) Gruppen=1001(Tim),33(www-data)

id www-data
uid=33(www-data) gid=33(www-data) Gruppen=33(www-data)