Gemeinsam genutzter Ordner für Mediendateien

Beginner Questions
1

Ich bin seit ein paar Tagen LibreWorkspace-Nutzer und versuche, eine Reihe von ext4-Partitionen allen Mitgliedern einer Benutzergruppe zugänglich zu machen.

Jeden der (unter /srv liegenden) Mountpoints

footage-archive
footage-raw
incoming
misc
photos
soundarchive
soundraw
tvarchive
tvraw

spreche ich im Folgenden mit L an.

Wie kann man die folgenden Anforderungen erfüllen?

  • Es gibt eine Gruppe media, der genau die drei Benutzer A, B, lw.Administrator angehören.
  • Es gibt ein Verzeichnis /srv/L, das ein Mountpoint für ein mit ext4 formatiertes Dateisystem ist. Insbesondere gibt es hier ein Verzeichnis /srv/L/lost+found, das nur root einsehen können soll.
  • Ansonsten sollen Mitglieder der Gruppe media in /srv/L lesen und schreiben, also Dateien und Verzeichnisse erstellen, ändern und löschen. Aber jeder Nutzer soll nur Daten, die er selbst erstellt hat, ändern oder löschen dürfen.
  • Wenn Nutzer A das Verzeichnis /srv/L/backup erstellt hat, dann soll auch Nutzer B die Datei /srv/L/backup/file.tgz erstellen können, und alle Nutzer der Gruppe media sollen sie lesen können (aber nicht ändern oder löschen!) (Dass man das Archiv bspw. auf einem Windows-System entpacken kann und dann die in den archivierten Daten enthaltenen Rechte außer Kraft sind, soll hier unberücksichtigt bleiben.)
  • Neu erstellte Dateien und Verzeichnisse sollen Group Ownership media haben, aber nur dann, wenn sie innerhalb von /srv/L erstellt werden.
  • Nutzer, die nicht der Gruppe media angehören, sollen lediglich Lesezugriff auf die Daten unter /srv/L haben.
  • Die Lösung muss auch für Nichtexperten praktikabel sein, d.h. auch wenn man in einem grafischen Programm „mal eben schnell“ eine Datei erstellt, soll sie diesen Beschränkungen unterworfen sein. Also kein händisches chmod oder Ähnliches.

Mein erster Vorschlag:

root# chown root:root /srv/L
root# chmod 2755 /srv/L
root# mkdir /srv/L/files # make extra directory to place files, so /srv/L/lost+found/ is protected
root# chown root:media /srv/L/files
root# chmod 3775 /srv/L/files

Das ist aber noch nicht ganz perfekt:

die standardmäßige umask ist 002, also:

Datei:       666 - 002 = 664  → rw-rw-r-- (Gruppe darf schreiben!)
Verzeichnis: 777 - 002 = 775  → rwxrwxr-x

chmod 0644 würde das lösen, ist aber nicht praktikabel.

Man könnte umask 0022 setzen:

Datei:       666 - 022 = 644 ⇒ rw-r--r--
Verzeichnis: 777 - 022 = 755 ⇒ rwxr-xr-x

Das gilt dann aber immer, auch für Verzeichnisse außerhalb von /srv.

Welche Nachteile hat es, wenn Benutzer A und B ihre umask auf 0022 setzen?

Sie sollen im Wesentlichen über den RDP-Desktop mit dem System interagieren,
das Terminal beherrscht nur Nutzer A (und lw.Administrator).

Zusammengefasst:
chmod 3775 und umask 0022: geht das oder handle ich mir damit Probleme ein?
Nutzer A hat primary group A. Sind die secondary groups relevant (außer media)?

Ich möchte ACLs vermeiden, da ich mich damit nicht gut auskenne.

2

Damit können wir den klassischen Ansatz meiner Ansicht nach nicht umsetzen.
Also wären hier meines Verständnisses nach ACLs notwendig.

Oder wir gehen über Gruppenordner/Integration über die Nextcloud, da kann man nicht alles der oben genannten Dinge umsetzen, wir kommen aber verdammt nah ran.

Mounten auf dem Desktop Modul schaffen wir für jeden Benutzer. Ist zwar etwas doppelt gemoppelt, habe ich aber so auf manchen Libre Workspace Servern so umgesetzt.
Da würde ein rclone über lokales WebDAV Sinn machen.

Ansonsten habe ich auch mal spaßeshalber Deine Nachricht in die KI reingeworfen, die sagt auch ACLs:
https://g.co/gemini/share/04b4347685a6

3

Neuer Lösungsvorschlag

Ansatz:
Wir legen einen neuen Benutzer an, der als Eigentümer der Daten fungiert, ohne sie selbst zu bearbeiten, und nutzen setGID und Sticky-Bit.

Details:

[A] Benutzer und Gruppen

Lege die Gruppe `media` an.

Füge die Benutzer `A`, `B` und `mediauser` dieser Gruppe hinzu.

[B] Eigentümer und Gruppen

Setze für alle Verzeichnisse den Benutzer `mediauser` als Eigentümer.

Setze die Gruppe `media` für alle Verzeichnisse.

[C] Berechtigungen

Für /srv/incoming:
A und B sollen dort Dateien schreiben und lesen können.
Das Verzeichnis /srv/incoming benötigt keine besonderen Bits (kein setgid, kein Sticky-Bit).

Für alle anderen Verzeichnisse:
Nur Lese- und Ausführrechte (z. B. r-x) für Gruppenmitglieder.
Setze das SetGID-Bit auf allen Verzeichnissen, damit neue Dateien/Verzeichnisse die Gruppe media erben.
Setze das Sticky-Bit auf allen Verzeichnissen, um unbefugtes Löschen zu verhindern (nur Eigentümer oder mediauser darf löschen).

[D] Automatisches Verschieben

Dateien, die in /srv/incoming abgelegt werden, sollen automatisch verschoben werden in eines der anderen Verzeichnisse (z. B. /srv/photos/files, /srv/tvraw/files etc.).

Beim Verschieben soll der Eigentümer auf mediauser geändert werden.

Die Dateien sollen danach nicht mehr durch A oder B gelöscht oder überschrieben werden können.

[E] Nachbearbeitung

Wenn A oder B eine Datei nachbearbeiten möchten, sollen sie diese nach /srv/toedit/ kopieren und dort bearbeiten können.

[F] Cronjob

Richte ein Skript ein, das täglich prüft, ob:

  1. alle Dateien/Verzeichnisse im Besitz der Gruppe media sind.

  2. alle Verzeichnisse unter /srv/*/files (außer /srv/incoming und /srv/toedit) das SetGID-Bit tragen.

Füge dieses Skript in die Crontab für root ein, sodass es täglich um 03:15 Uhr ausgeführt wird.

–

Das werde ich in den nächsten Tagen ausarbeiten und dann hier vorstellen.

Habe ich hier etwas Wesentliches übersehen?