Ordner für gemeinsamen Zugriff organisatorisch überlegen

linuxnutzer

Captain
Registriert
Dez. 2011
Beiträge
3.329
Es geht um ein grundsätzliches Konzept für Xubuntu und Kubuntu-PCs, also Thunar und Dolphin als Dateimanager.

Früher mal, war das Home-Verzeichnis für andere User lesbar, das ist nicht mehr so.

Es geht nun darum, dass alle User die Screenshots eines Users lesen können sollen, der User, der den Screenshot (mit seinem Login) erstellt hat, soll ihn auch bearbeiten oder löschen dürften. Netzwerkzugriff wird nicht benötigt und ist auch nicht gewünscht.

Wie mache ich das jetzt am besten und vor allem ohne großen Aufwand. Mir fallen nur komplizierte Dinge ein, die ich meinen Familienmitgliedern nicht zumuten will.
 
Also die verschiedenen User teilen sich sich gemeinsam die Hardware, oder wie soll das ohne Netzwerkzugriff gehen?
Und nur der erstellende User darf Schreib-/Löschrechte haben, die anderen reine Leserechte im Screenshot-Ordner?
Oder wäre es auch ok, wenn alle Nutzer bearbeiten/löschen können, und das Lesen ist nur die Minimalanforderung?
Ah, und meinst du es gibt nur einen Nutzer der Screenshots anfertigt, oder jeder soll Besitzer seiner Screenshots sein und alle anderen lesen?
 
  • Gefällt mir
Reaktionen: linuxnutzer
linuxnutzer schrieb:
Wie mache ich das jetzt am besten und vor allem ohne großen Aufwand
Wie wäre es denn mit einem Austauschverzeichnis, auf das alle User lesend zugreifen dürfen (r.x) ?

Man hat also quasi im Account-Management eine gemeinsame Gruppe users in der auch alle Benutzer-Accounts drin sind. Und der Nutzer, der Screenshots machen kann heißt jetzt von mir aus shooter. Und das Austauschverzeichnis ist von mir aus unter /var/sharedir

Code:
ls -al /var/sharedir

drwxr-x---  5 shooter  users     30 Nov 2025 ./
drw-r-----  5 shooter  users     30 Nov 2025 myscreenshot01.png
 
  • Gefällt mir
Reaktionen: linuxnutzer
Thorakon schrieb:
Also die verschiedenen User teilen sich sich gemeinsam die Hardware

Ja, wobei eine physische Person mehrere User aus Sicherheitsgründen haben kann. Internetbanking läuft zB per einen eigenen Linux-User.

Also mehrere physische Personen mit jeweils 2-3 User-Konten auf 1 Notebook.

Thorakon schrieb:
Und nur der erstellende User darf Schreib-/Löschrechte haben, die anderen reine Leserechte im Screenshot-Ordner?

Das könnte man diskutieren, aber eigentlich ja.

Thorakon schrieb:
Ah, und meinst du es gibt nur einen Nutzer der Screenshots anfertigt, oder jeder soll Besitzer seiner Screenshots sein und alle anderen lesen?

Ja wieder so, aber diskutierbar.

andy_m4 schrieb:
Wie wäre es denn mit einem Austauschverzeichnis, auf das alle User lesend zugreifen dürfen (r.x) ?

Eher nicht, der eine User soll (ungewollt) dem anderen User keine Screenshots löschen können. Jeder User kann sich die Screenshots vom anderen User in seinen Bereich kopieren können. Die User sind alle vertrauenswürdige Familienmitglieder.

Die Screenshots sind nur ein Beispiel, weil des meistens der Anwendungsfall ist, aber eigentlich geht es um beliebige Dateien.
 
linuxnutzer schrieb:
Eher nicht, der eine User soll (ungewollt) dem anderen User keine Screenshots löschen können. Jeder User kann sich die Screenshots vom anderen User in seinen Bereich kopieren können.
Wie Du anhand meines Beispiels siehst, dürfen andere Nutzer zwar lesen aber nicht aus /var/exchange löschen. Das bleibt shooter vorbehalten. Kopieren geht dann natürlich selbstredend auch.
 
  • Gefällt mir
Reaktionen: linuxnutzer
andy_m4 schrieb:
Wie Du anhand meines Beispiels siehst

Ich habe dein Beispiel noch nicht ganz verstanden. Dahinter stecken dann noch weitere komplizierte Dinge bei der Screenshoterstellung. Ich hoffe ich kann die Shortcuts dafür mal beiseite lassen.

Muss ich dann das Screenshot-Programm in eine Gruppe stecken?

Der Ersteller soll natürlich den Screenshot löschen dürfen, die anderen nicht.
 
linuxnutzer schrieb:
Muss ich dann das Screenshot-Programm in eine Gruppe stecken?
Nein. Es geht um die Nutzer-Accounts.
Vielleicht solltest Du Dich mit der grundlegenden Nutzer-, Gruppen- und Rechteverwaltung vertraut machen. Daraus erklärt sich das meiste schon fast von alleine.
Dazu gibts auch sehr viel Material im Internet (wie beispielsweise hier: https://de.wikibooks.org/wiki/Linux-Praxisbuch/_Benutzerverwaltung).

Kurz stichpunktartig gesagt:
  • es gibt auf einem UNIX-System Benutzer mit einem Namen. Es gibt auch Benutzergruppen die ebenfalls namentlich bezeichnet sind.
  • ein Benutzer ist Mitglied in ein oder mehreren Benutzergruppen
  • eine Datei oder ein Verzeichnis ist Eigentum eines Benutzers und einer Gruppe
  • Für eine Datei bzw. ein Verzeichnis werden immer 3 Rechte vergeben:
    nämlich das der besitzende Benutzer darf, was die besitzende Benutzergruppe darf und was alle anderen dürfen
  • wichtige Konsolenbefehle rund um die Thematik: id, chown, chgrp, chmod, addgroup, usermod
    man kann solche Dinge auch oftmals über die GUI regeln
 
andy_m4 schrieb:
Kurz stichpunktartig gesagt:

Das ist eigentlich bekannt, richtig und intelligent anwenden ist eine andere Sache.

Es werden auch "authorized_keys" verwendet, da darf ich den User nicht in 2 Gruppen stecken, sonst funktioniert die Authentifzierung nicht mehr.

andy_m4 schrieb:
Nein. Es geht um die Nutzer-Accounts.

Das wäre ja das spannende.

Ich nehme mal an, es ist egal wo das entsprechende Verzeichnis ist.

Code:
root@nb:~# ls -la /daten/
insgesamt 4
drwxr-xr-x  3 ec   ec     21 Nov 30 01:26 .
drwxr-xr-x 25 root root 4096 Nov 30 01:40 ..
drwxr-xr-x  4 ec   ec    153 Nov 30 19:11 install

Nehmen wir jetzt mal an die User ec und ab sind sudoer und der Mountpoint /daten/ gehört ec. Weitere user sind keine sudoer, zB der User id.

Unterhalb von /daten könnte man ein Verzeichnis Screenshots machen. In /var sind sie weg, wenn man neu installiert.

"other" kann lesen, also alles ok bzgl. lesen.

Bei Schreiben blicke ich noch nicht durch, wie man das am besten organisiert. Eventuell für jeden User unterhalb von /daten ein eigenes Verzeichnis für die Screenshots machen?

Die Frage ist, wie man mit chown, chmod und Gruppen trickst, aber das soll nicht zu kompliziert werden.

Ich habe jetzt mal versucht, aber ob man das besser machen kann, ist die Frage:

Der User ec nutzt das Notebook hauptsächlich und bekommt für Daten ein eigenes Verzeichnis / Partition, die anderen müssen in /home das Auslangen finden.

Code:
# ls -la /daten/
insgesamt 4
drwxr-xr-x  4 ec   ec     41 Nov 30 20:22 .
drwxr-xr-x 25 root root 4096 Nov 30 01:40 ..
drwxr-xr-x  3 ec   ec     21 Nov 30 20:22 daten_ec
drwxr-xr-x  5 root root   73 Nov 30 20:24 screenshots

und darunter dann:

Code:
# ls -la /daten/screenshots/
insgesamt 0
drwxr-xr-x 5 root root 73 Nov 30 20:24 .
drwxr-xr-x 4 ec   ec   41 Nov 30 20:22 ..
drwxr-xr-x 2 ab   ab    6 Nov 30 20:24 screenshots_ab
drwxr-xr-x 2 ec   ec    6 Nov 30 20:24 screenshots_ec
drwxr-xr-x 2 ida  ida   6 Nov 30 20:24 screenshots_ida

So ist das schon ziemlich aufwendig, sind ja nur Beispieluser.
 
Zuletzt bearbeitet:
Ordner mit Stickybit verwenden (chmod 1777 MySharedFolder).
 
  • Gefällt mir
Reaktionen: Thorakon und andy_m4
linuxnutzer schrieb:
Es werden auch "authorized_keys" verwendet, da darf ich den User nicht in 2 Gruppen stecken, sonst funktioniert die Authentifzierung nicht mehr.
Das sollte eigentlich egal sein.

Ich meine, du kannst das mit den Gruppen auch weg lassen. Das brauchst Du ja strenggenommen nur, wenn es auf dem PC Nutzeraccounts gibt, die nicht auf /daten/screenshots zugreifen können dürfen.
Ansonsten kannst Du das ja auch über "other" lösen.
Dazu unten mehr.

linuxnutzer schrieb:
Ich nehme mal an, es ist egal wo das entsprechende Verzeichnis ist.
Ja. Das ist egal.

linuxnutzer schrieb:
Bei Schreiben blicke ich noch nicht durch, wie man das am besten organisiert.
Schreiben ist ja nicht das Problem. Der Benutzer ec bracht ja lediglich Schreibrechte auf dem Verzeichnis und er ist ja auch automatisch Eigentümer aller von ihm erstellen Dateien (also auch der Screenshots die er macht).
Also braucht man ja für das Verzeichnis nur ihn als Eigentümer eintragen
chown ec /daten/screenshots
und entsprechend die Rechte zu setzen:
chmod u+rwx /daten/screenshots

Wenn man jetzt noch "other" benutzt, setzt man auch die Rechte für das Verzeichnis entsprechend:
chmod o+rx,o-w /daten/screenshots
und wenn Du dafür keine Benutzergruppen nutzt, kannst Du da im Prinzip alles wegnehmen:
chmod g+rwx /daten/screenshots

Jetzt geht es noch darum, das von ec neu erstelle Dateien auch so erstellt werden, das ec Lese- und Schreibrecht hat und alle anderen Nutzer ("other") nur Leserechte.
Der traditionelle Weg ist das mit umask zu machen. Damit das nicht dauerhaft geändert wird am besten beim Aufruf des Screenshot-Tools:
umask 022 ; screenshot-tool

Man kann aber auch Access-Control-Lists (ACLs) benutzen, um direkt im Verzeichnis /daten/screenshots zu hinterlegen, welche Rechte bei neu erstellten Dateien (automatisch) vergeben werden:
setfacl -d -m u::rw,g::r,o::r-- /daten/screenshots
Siehe dazu auch https://wiki.ubuntuusers.de/ACL/ und insbesondere auch den Abschnitt über Vererbung.

Sticky-Bit dafür benutzen geht natürlich auch.
 
andy_m4 schrieb:
Das sollte eigentlich egal sein.

Da habe ich mir gestern die Zähne ausgebisse. Wenn in /etc/group ein User 2 Gruppen definiert hat, wird nach dem PW gefragt.

andy_m4 schrieb:
Ich meine, du kannst das mit den Gruppen auch weg lassen. Das brauchst Du ja strenggenommen nur, wenn es auf dem PC Nutzeraccounts gibt, die nicht auf /daten/screenshots zugreifen können dürfen.

Darüber hatte ich auch schon nachgedacht. Alle die in users sind dürfen die Screenshots auch sehen.

andy_m4 schrieb:
Der Benutzer ec bracht ja lediglich Schreibrechte auf dem Verzeichnis

Dm Nutzer ec gehörte ja der ganze Mountpoint, also hat er auch Schreibrechte, nur die anderen (noch) nicht.

andy_m4 schrieb:
Also braucht man ja für das Verzeichnis nur ihn als Eigentümer eintragen

Es reicht also 1 Verzeichnis, wo alle Screenshots hinein gschrieben werden, wenn ich dich richtig verstehe.

Das was du bis jetzt beschrieben hast, ist eigentlich alles default, aber kann man natürlich noch einmal machen.

andy_m4 schrieb:
Der traditionelle Weg ist das mit umask zu machen. Damit das nicht dauerhaft geändert wird am besten beim Aufruf des Screenshot-Tools:

Mit Screenshot-Tool meinst jetzt das Programm, das den Screenshot erstellt? Ich frage das deswegen, damit es da kein Missverständnis gibt. Da ist noch einiges nicht klar, wie ich das mache. Jedenfalls soll das ein schneller Einzeiler über Kurzbefehl sein. Jeder zusätzliche Befehl kostet Zeit.

Ich mache ein eigenes Thema zu den Screenshots, das ist kompliziert. Man muss zwischen X11 und Wayland unterscheiden, etc.

Zur Screenshot-Diskussion:
https://www.computerbase.de/forum/threads/screenshot-nach-stdout.2259489/

Also jedesmal umask aufrufen, gefällt mir nicht so.

andy_m4 schrieb:
Man kann aber auch Access-Control-Lists (ACLs) benutzen

Das müssen meine Familienmitglieder selber machen, fürchte das klaptt nicht.

andy_m4 schrieb:
Sticky-Bit dafür benutzen geht natürlich auch.

Das schaue ich mir an.
 
Uridium schrieb:
Ordner mit Stickybit verwenden (chmod 1777 MySharedFolder).

Muss das zwingend 777 sein? Ich würde gerne others ausschließen und nur die "users" erlauben.
Ergänzung ()

Ich überlege gerade, ob es in 1 Ordner nicht zu unübersichtlich wird.

Code:
time maim -i $(xdotool getactivewindow)  | convert - -resize 1600x -quality 20 "$HOME/Bilder/screenshots-$USER/screenshot_$(date +'%Y-%m-%d_%H-%M-%S').jpg"

Man kann in den automatischen Dateinamen den User integrieren, bei vielen Screeshots, die nur das Datum enthalten, wird es trotzdem unübersichtlich.
 
Zuletzt bearbeitet:
Uridium schrieb:
Musst Du selbst mal testen.

Ich bin mir noch nicht sicher wie ich die Gesamtsituation beurteile. StickyBit ist sicher sehr interessant.

Es um geht um ca. 10 PCs in der Familie mit ca. 6 User pro PC, von denen ein paar auch öfters neu nach Tests installiert werden und somit die Verzeichnisse neu eingerichtet werden müssen.

Damit bin ich auf 60 verschiedenen Screenshot-Verzeichnissen.

Ich überlege mir diese Screenshot-Verzeichnisse automatisch per Script als root zu erstellen und im Script kann man auch einmalig die Rechte definieren, die man braucht.

Speziell zum Testen, sollte der Code aber möglichst peformant sein.

Code:
$ grep users /etc/group
users:x:100:ab,ec

Das sind dann in der Regel mehr User. Wie lege ich als root (führt das Script aus) effizient für jeden User ein nicht vorhandenes Verzeichnis an. Vermutlich ist "mkdir -p" am einfachsten.

Es müssen also die Verzeichnisse für diesen Befehl vorhanden sein und die entsprechenden Rechte durch root mit chown und eventuell chmod einmalig gesetzt werden.

Code:
maim | convert - -resize 1600x -quality 20 "$HOME/Bilder/screenshots-$USER/screenshot_$USER""_$(date +'%Y-%m-%d_%H-%M-%S').jpg"

Ich glaube in dieser Variante ist das stickybit nicht mehr notwendig. Da definiere ich die Rechte per Script.
 
StickyBit ist auch eher für einen gemeinsamen Shared Folder gedacht. Wenn Du eh für jeden User einen eigenen Ordner erstellen willst, kannst Du die normalen Dateirechte nehmen.

Für die Neueinrichtung eines Users gibt es /etc/skel als Vorlage für den /home Ordner (falls hilfreich) und bei Debian gab es mal eine 'adduser.local' Datei (script), die bei Neuerstellung eines Users ausgeführt wurde. Vielleicht gibt es da mittlerweile was aktuelleres.
 
Zuletzt bearbeitet:
Uridium schrieb:
Wenn Du eh für jeden User einen eigenen Ordner erstellen willst,

Die Überlegungen kommen erst mir der Diskussion, ich glaube es wird mit einem gemeinsamen Ordner zu unübersichtlich, auch wenn man den User in den Dateinamen schreibt. Ich tüftle da herum und bin jetzt bei einem Shellscript für den Shortcut gelandet.

Code:
#!/bin/bash
#bash -c '/usr/local/bin/screenshot_active_x11.sh'
maim -i $(xdotool getactivewindow) | convert - -resize 1280 -quality 20 "$HOME/Bilder/screenshots-$USER/screenshot_${USER}-$(date +%Y-%m-%d_%H-%M-%S)_active.jpg"
exit

Insofern glaube ich auch, dass ich mir das sticky bit sparen kann.

Uridium schrieb:
Neueinrichtung eines Users gibt es /etc/skel als Vorlage für den /home Ordner

Da weiß ich noch gar nicht was ich will bzw. am sinnvollsten ist. In /home ist es sicher am einfachsten, weil das existiert, aber lieber wäre mir eine Partition, die bei der Installation nicht formatiert wird.

Uridium schrieb:
die bei Neuerstellung eines Users ausgeführt wurde

Das muss man aber auch wieder vorbereiten. Es sollte möglichst einfach sein und da denke ich an ein Script als User nach dem Neustart ausführen oder vielleicht so:

Code:
#!/bin/bash
#bash -c '/usr/local/bin/screenshot_active_x11.sh'
rechnername=$(uname -n | cut -f1 -d".")
screenshot_pfad="$HOME/Bilder/screenshots-$USER-$rechnername"
screenshot_datei=${screenshot_pfad}/screenshot_${USER}_${rechnername}-$(date +%Y-%m-%d_%H-%M-%S)_active.jpg
if [ ! -d "$screenshot_pfad" ] ; then
    mkdir -p "$screenshot_pfad"
fi
maim -i $(xdotool getactivewindow) | convert - -resize 1280 -quality 20 ${screenshot_datei}
exit

Das dauert ja gar nicht so lange.

Code:
$ time /usr/local/bin/screenshot_active_x11.sh

real    0m0.304s
user    0m0.405s
sys    0m0.305s

PS: Ich ändere Kleinigekeiten beim Code und aktualisiere dann. Manche Dinge brauchen gar nicht viel Zeit. Ich habe jetzt den User und den Rechnernamen in den Dateinamen integriert.

"screenshot_pfad" kann man jetzt dynamisch nach "rechnername" definieren, sollte auch nicht viel Zeit brauchen. Bis jetzt hält sich alles in Grenzen.

Code:
-rw-rw-r--

User und Gruppe bin ich selber, others kann lesen. Das könnte man vielleicht optimieren.
 
Zuletzt bearbeitet:
Also irgendwie habe ich beim Vererben der Rechte noch Probleme.

Code:
if [ ! -d ${screenshot_pfad} ] ; then
    mkdir -p ${screenshot_pfad}
    chown -R $USER:users ${screenshot_pfad}
    chmod 750 -R ${screenshot_pfad}
    chmod +s ${screenshot_pfad}
fi

Wenn der Ordner neu angelegt wird, soll der das User-Script die Rechte setzen. Die erstellte Datei darf aber dann von others zugegriffen werden, so wie oben ausgeführt.

-rw-rw-r--

Das ist natürlich nicht gewollt, wenn ich auf die Gruppe users ändere, die kann nämlich so schreiben.

Wenn ich danach ein 2. Mal ausführe:

Code:
chmod 750 ${screenshot_datei}
Dann erhalte ich:

-rwxr-x---

Bei zeitkritischen Dingen ist das natürlich ein Problem.

PS: Sorry für die unterschiedliche Notation manchmal, schreibe mich mit der alten leichter.
 
Zuletzt bearbeitet:
Zurück
Oben