[LUGA] Mit freundlicher Unterstützung von:
WSR

Mail Thread Index


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [luga] UID GID Frage



[Teil 2: Permissions am lokalen Rechner]

On 2016-10-09 17:59:20 +0200, Martin Bammer wrote:
> Neben dem Problem mit UIDs und GIDs fällt mir auch noch das Sharing von Dateien
> auf einem Computer ein. Mit dem Sharing meine ich jetzt das Teilen von Dateien
> auf ein und demselben PC zwischen mehreren Benutzern.
> Beispiel: Auf einem Familien-PC werden Urlaubsbilder gespeichert. Dateisystem
> ist EXT4. Per Default bekommen die Dateien UID und GID vom Benutzer der die
> Dateien auf den PC spielt. Die Zugriffsrechte werden entsprechend so gesetzt
> dass andere Benutzer NICHT darauf zugreifen können. Zumindest nicht schreibend.
> Echt ärgerlich sowas.
> Es gibt dafür eine einfache Lösung: Einen Ordner mit einer eigenen Sharing-
> Gruppe anlegen, und das Group-Sticky Bit setzen. Alle Benutzer sind Mitglied bei
> dieser Gruppe. Eigentlich einfach, nur: Ein einfacher User kann so etwas niemals
> einrichten. Dem fehlt dafür einfach das Wissen.

Das funktioniert auch nur dann, wenn die umask 00x ist. Ist bei manchen
Distributionen der Fall (ich glaube, Redhat hat als erstes dieses Schema
eingesetzt), bei anderen nicht.

Ich gebe dir hier recht: Unix-Permissions sind nicht besonders
praxisgerecht.

Die Kardinalsünde ist die umask: Die Permissions, die neu angelegte
Files haben, an eine Eigenschaft des Prozesses zu koppeln und nicht an
das Directory, war eine blöde Idee. Es war schon zu Zeiten, als es nur
terminal-basierte Shells gab, blöd: Nach jedem cd zu überlegen, ob man
jetzt eine andere umask setzen muss, ist einfach zu fehlerträchtig.
Leute haben das schon damals dauernd vergessen und Permissions waren
dann zu restriktiv oder zu offen. Mit der Einführung von graphischen
Benutzeroberflächen, wo es kein current working directory mehr gibt, war
das dann endgültig unpraktikabel. Die umask einfach auf 002 oder 007 zu
setzen, deckt einen wichtigen Spezialfall ab, ist aber auch keine
allgemeintaugliche Lösung.

Das zweite Problem (das sich Linux leider ohne besondere Not eingetreten
hat) ist die Verwendung der effektiven GID für neu angelegte Files.
Gleiches Problem wie oben: Es ist eine Eigenschaft des Prozesses, nicht
des Directorys, aber normalerweise will man Permissions innerhalb eines
Directory-Baums konsistent halten und nicht innerhalb einer
Shell-Session. BSD hat mit der Einführung der supplementary Groups auch
die Wahl der Gruppe erweitert: Da ein Prozess nun mehrere Gruppen haben
konnte, wurde bevorzugt diejenige des Parentdirectorys verwendet. System
V hat aus irgendeinem Grund statt dessen den setgid-Murks eingeführt.
Linux hat dann beides implementiert aber leider die SysV-Lösung zum
Default erhoben (bsdgroups ist schnell ins fstab geschrieben, aber man
muss es wissen)

Und das dritte Problem ist, dass man mit Rechten für einen Benutzer,
eine Gruppe und den Rest der Welt oft nicht auskommt. Häufig braucht man
zumindest zwei Gruppen (eine die nur lesen darf und eine, die lesen und
schreiben darf).

Inzwischen gibt es aber seit vielen Jahren eine Lösung für diese
Probleme: POSIX ACLs.

POSIX ACLs erlauben es, sowohl Rechte für mehrere Benutzer und Gruppen
zu vergeben, als auch diese Rechte an neu angelegte Files (und
Subdirectorys) zu vererben. 

Unglücklicherweise werden die recht stiefmütterlich behandelt. Selbst
Commandlinetools, die damit umgehen können (z.B. rsync) ignorieren sie,
wenn man nicht eine spezielle Option angibt (bei rsync reicht "-a"
nicht, man braucht "-a -A") und wenn die üblichen Filemanager Funktionen
für ihre Verwaltung anbieten, dann so gut versteckt, dass sie mir bisher
nicht aufgefallen sind (das kann natürlich auch daran liegen, dass ich
die selten verwende und z.B. den aktuellen Stand von Gnome Nautilus oder
KDE Dolphin gar nicht kenne).


> Eine alternative Lösung wäre noch FAT zu verwenden, aber dann verliert man
> sämtliche Metadaten.
> Wenn nun die Linux-Distros diese gerade beschriebene Lösung vorinstallieren
> würden dann hätten viele Benutzer schonmal ein Problem weniger.

Welche Lösung? "Einen Ordner mit Sticky-Bit anlegen" kann nicht
vorinstalliert werden, jedenfalls nicht sinnvoll. Die bsdgroups
Mount-Option könnte per default gesetzt sein, aber auch dann muss man
noch eine Gruppe und ein Directory anlegen und der Gruppe die
Schreibrechte für das Directory geben. 

        hp

-- 
   _  | Peter J. Holzer     | You can do reverse engineering,
|_|_) | Schriftführer LUGA  | but you can't do reverse hacking.
| |   | hjp@luga.at         |
__/   | http://www.luga.at/ | -- Vilayanur S. Ramachandran

Attachment: signature.asc
Description: Digital signature



powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
Oktober 2016