Dateirechte auf Default bzw. 770 zurücksetzen

[Geeky26]

Auf einer meiner Festplatten herscht ein kleines Dateirechte-Chaos. Alle Dateien und Verzeichnisse haben Chmod 775 - es ist meine Datenplatte, nicht Systemplatte.
Owner und Group dürfen alles, Public darf lesen und ausführen.

Ich würde gerne 770 (Public darf nix) über die gesamte Festplatte haben, user:group-Berechtigungen sollen so bleiben wie sie sind.

Ist 770 in Ordnung? Die Festplatte ist, wenn eine VPN-Verbindung zum Server (zu Hause) besteht, mit dem MiXplorer (Android) einsehbar, jedoch nur wenn man Zugangsdaten hat. Deswegen soll nur Owner und Group Berechtigungen haben.
Im Samba-Share ist auch hinterlegt, welche Gruppe und welche Nutzer überhaupt Zugriff haben.

 

[andy_m4]

Ich würde gerne 770 (Public darf nix) über die gesamte Festplatte haben

Über die gesamte Festplatte ist wohl eher nicht so gut. Es gibt durchaus nicht wenige Dateien die darauf angewiesen sind zumindest "readable" zu sein. Für Userdaten kann man das machen. Für "Systemdateien" würde ich eher es so machen, wie die Distribution es vorgibt (und von da aus kann man dann meinetwegen noch gezielte Einschränkungen machen).
Das x-Attribut sollte man auch nicht großzügig setzen. Das ist bei Dateien für ausführbare Dateien (Programme, Skripte etc.) gedacht. Lediglich bei Verzeichnissen macht das Sinn, weil es dort bedeutet, dass man diese "betreten" darf.
Ob die Gruppe alles darf, solltest Du Dir auch überlegen. Oft reichen Leserechte völlig aus.

Ansonsten lautet der Befehl
find path -exec chmod 770 {} \;
wobei für path der gewünschte Pfad angegeben werden muss von dem aus man rekursiv in die Tiefe gehend für alle Dateien und Verzeichnisse die 770 gesetzt werden sollen.

Für sinnvoller halten würde ich aber sowas wie:

find path -type f -exec chmod 660 {} \;
(nur Dateien mit rw-Rechten versehen)
Wenn Du vereinzelt noch das eXecutable-Bit brauchst, dann würde ich es gezielt setzen statt mit der Gießkanne.

find path -type d -exec chmod 770 {} \;
(bei Verzeichnissen kommt noch das x-Attribut dazu)

Und wie gesagt. Eher nur für Nutzdaten (z.B. alles was in /home liegt) und nicht fürs System selbst.

 

[Geeky26]

Ich habe oben noch anbgefügt, dass es sich um meine Datenplatte, nicht Systemplatte handelt.
Executable brauche ich eigentlich nicht, kann weg.

Wenn ich mein Testverzeichnis auf 660 stelle, komme ich nicht ins Verzeichnis. Weder Windows noch mit cd über SSH.

drw-rwS--- 2 Server users 6 1. Okt 10:18 _test2

Setze ich 770, klappts.

drwxrws--- 3 Server users 51 1. Okt 10:16 _test

Ein Verzeichnis über Windows erstellt, ergibt drwxrws---.
Ein Verzeichnis über SSH erstellt, ergibt drwxr-sr-x.

Das ist jetzt etwas blöd. Heißt also, keine Verzeichnisse über SSH erstellen.

 

[andy_m4]

Exedcutable brauche ich eigentlich nicht, kann weg.

Für Verzeichnisse wirst Du es brauchen.

Wenn ich mein Testverzeichnis auf 660 stelle, komme ich da über SSH (lokal im Netzwerk) nicht mehr mit cd rein, obwohl der SSH-Nutzer in der users-Gruppe ist.

Was auch immer Dein Testverzeichnis ist.
Was meldet denn der SSH-Client als Fehler? Und was loggt der SSH-Server?
Möglicherweise ist hier auch gar nicht ein "zu wenig Rechte" das Problem, sondern ein zuviel. Im Homeverzeichnis sollten sowohl das Unterverzeichnis .ssh als auch die in ihm enthaltenen Dateien nur vom User/Eigentümer beschreibbar sein.
Konkret steht in der ssh-config-Manpage:

~/.ssh/config
This is the per-user configuration file. The format of
this file is described above. This file is used by the SSH
client. Because of the potential for abuse, this file must
have strict permissions: read/write for the user, and not
writable by others.

 

[0x7c9aa894]

chmod geht auch recursive also chmod -R

Also chmod -R o-rwx <pfad> entfernt die Flags für alle Anderen (others) die nicht Besitzter oder Gruppe sind

Ergänzung (1. Oktober 2022)

ergibt drwxrws---.

Versicht mit dem 's'! Das ist ein sticky bit. mach mal stat <verzeichnis>

 

[Geeky26]

Im Homeverzeichnis sollten sowohl das Unterverzeichnis .ssh als auch die in ihm enthaltenen Dateien nur vom User/Eigentümer

Die Systemplatte möchte ich gar nicht ändern sondern eine andere Festplatte wo keine Systemdaten drauf sind.

Versicht mit dem 's'! Das ist ein sticky bit.

Das wird automatisch hinzugefügt, wenn ich am Windows-Rechner ein Verzeichnis auf dem Samba-Share erstelle.

Ich habe über die ganze Platte (private Daten, kein System) eben mal o-rwx durchlaufen lassen, das ist ja schonmal ein Anfang.

 

[andy_m4]

Die Systemplatte möchte ich gar nicht ändern sondern eine andere Festplatte wo keine Systemdaten drauf sind.

Ähm ~./.ssh liegt im Homeverzeichnis und nicht in den Systemverzeichnissen.
Mal abgesehen davon war das ja auch nur eine Vermutung. Die Fehlermeldung des ssh-Clients und die Logs des SSH-Servers geben zur Ursache es Login-Problems sicher die passenden Hinweise.

 

[Geeky26]

Ich habe überall o-rwx drüberlaufen lassen, das reicht mir aus.

 

[0x7c9aa894]

Das 's' bei der Gruppe ist eine 'setgid' bit. Bei Verzeichnissen bedeutet dies, daß alle neuen Dateien, die gleichen Guppen Berechtigungen erhalten wie diese. Das macht Sinn bei geteilten Laufwerken. Also mal testhalber eine neue Datei erstellen, und schauen ob alles OK ist.

 

[Geeky26]

Ich habe das so eingestellt, dass neue Dateien mit 660 (-rw-rw----) erstellt und neue Verzeichnisse mit 770 (drwxrwx---, wenn das Verzeichnis vorher kein s-bit hat) erstellt werden.

Ist es sinnvoll, das sticky-bit zu entfernen?
find path -type f -exec chmod -t {} \; find path -type d -exec chmod -t {} \;