AW: [linux-l] Linux-Dateirechte reichen nicht !!

[Steffen Dettmer]

* Guntram Trebs wrote on Fri, Oct 04, 2002 at 18:49 +0200:
> On Fri, 4 Oct 2002, Steffen Dettmer wrote:
> > * Roland Penzin wrote on Fri, Oct 04, 2002 at 10:21 +0200:
> > Ich weiß nicht, für so ein Standardproblem, wie der Poster hatte,
> > braucht man doch keine ACLs! Ich meine, Unix arbeitet seit 20
> 
> Dann gib doch "einfach" mal eine Standard-Lösung für das Problem an.

Wie gesagt, daß was ja nicht klar beschrieben (IIRC).

> > Jahren mit den "einfachen" Rechten, und irgendwie funktioniert es
> > eigentlich immer. Natürlich kann es umständlich werden, wenn man
> > 100 User hat, und *jede* Kombination von Berechtigungen, das sind
> 
> genau in diesem Fall wird es umständlich

Ja, aber 100 verschiedene Userberechtigungen sind sehr
theoretisch.

> > 10.000 Konfigurationen! Bloß sowas hab ich in der Praxis einfach
> 
> wie Du auf die 10.000 kommst, verstehe ich nicht.

Wenn es insgesammt nur 100 Dateien gäbe, könnte man 100x100
ansetzen. Da gäbe es dann natürlich nur sehr ausgewählte
Konfigurationen. Na ja, bei sowas hört meine Vorstellungskraft
einfach mal auf :)

> Bei 100 Usern komme ich auf 2^100 verschiedene mögliche Gruppen, die
> es geben könnte.
> 
> (jede Gruppe könnte durch eine hundertstellige Binärzahl eineindeutig
> beschrieben werden, wobei die i-te Stelle der Binärzahl angibt, ob
> Benutzer Nr. i in dieser Gruppe ist)

Klingt erstmal plausibel...

> 10.000 und 2^100 sind verdammt unterschiedlich große Zahlen.

Yep, 2^100 == 1267650600228229401496703205376

> 2^100 hat ungefähr 30 Dezimalstellen.

Sogar genau :)

> Du sagst es, es geht auch mit weniger Gruppen. Man muß also nicht ACL's
> mit 10.000 unterschiedlichen Gruppen prüfen.

Ja, in der Praxis hab ich sowas noch nie gesehen. Es gibt einfach
nicht jede denkbare Rechtekonfiguration in der Praxis. Das kann
eh niemand mehr verwalten; ob man das nun per ACL (dann braucht
man ja je Datei ne ACL mit bis zu 100 Einträgen) oder anders
macht. Dann denkt man meistens schon vorher falsch. Wenn man sich
solche Probleme in der Praxis anguckt, sieht man meistens, daß es
in Wirklichkeit nur wenige Rollen gibt: welche, die alles dürfen,
viele, die wenig schreiben und vor allem nicht alles lesen
dürfen, dann findet man vielleicht 20 Rollen. Meistens hängt das
mit der Anzahl der Abteilungen zusammen. Selten hat man viele
(!) Fälle, daß die Sekretärin aus Abteilung B einige Dateien aus
Abteilung A schreiben darf, andere jedoch nicht, und der Chef die
Dateien überhaupt nicht lesen darf. Sowas hat man einfach nicht.

> Das Problem ist, daß manche Probleme mit der normalen
> Benutzerverwaltung ebend nicht gehen.

Theoretisch, schon. Aber die Beispiele, die ich so gehört hab,
ließen sich meistens auch mit Unix-Rechten machen. Ich hab ACLs
oft bei Netware gesehen, und das meiste davon, was kompliziert
war, war falsch. Eigentlich hätte dann auch der Chef die Datei
schreiben dürfen, klar, er ist ja der Chef, aber es gab eben so
ne ACL einfach mal nicht.

> ich meine, ich hab das Problem verstanden, aber hier nochmal ein ganz
> konkretes Beispiel:
> 
>  - 5 user: doreen, lutz, norbert, susi, ralf
>  - ein Verzeichnis: /projekte/supergeheim/
>  - doreen und lutz sollen unterhalb von /projekte/supergeheim/ alles lesen
>    und schreiben können
>  - norbert und susi sollen unterhalb von /projekte/supergeheim/ alles
>    lesen, aber nichts schreiben können
>  - ralf sowie alle anderen sollen unterhalb von /projekte/supergeheim/
>    nichts lesen und nichts schreiben können
> 
> (so habe ich das Problem verstanden)

Doreen und Lutz nenn ich mal "sgleitung", weil die alles dürfen.
Beide sind zusätzlich in der Gruppe "sg" mit norbert und susi.

1. Gruppe "sg": doreen, lutz, norbert, susi
2. Gruppe "sgleitung": doreen, lutz

chown doreen:sg /projekte/supergeheim/
chmod 
> 
> und um das gleich auszuschließen:
> Es soll kein weiterer Benutzer extra wegen dieses Projektes angelegt
> werden.
> 
> Natürlich könnten sich doreen und lutz einen gemeinsamen Account bekommen
> und mit diesem dort reinschreiben. Das hat aber wieder andere Nachteile
> und ist deshalb keine Lösung ...

Doreen und Lutz nenn ich mal "sgleitung", weil die alles dürfen.
Beide sind zusätzlich in der Gruppe "sg" mit norbert und susi.

1. Gruppe "sg": doreen, lutz, norbert, susi
2. Gruppe "sgleitung": doreen, lutz
 
> Viel Spaß beim Rumprobieren, behalte aber immer im Auge, daß es
> möglicherweise keine vernünftige Lösung für das Problem gibt ...

In der Praxis würde ich ein Verzeichnis 
/projekte/supergeheim/dateien/
anlegen. Dann die anderen aussperren:
chown root:sg /projekte/supergeheim/
chmod 0750 /projekte/supergeheim/
und dann die Schreibberechtigungen:
chown root:sgleitung /projekte/supergeheim/dateien/
chmod 2775 1 /projekte/supergeheim/dateien/

Dateien unter /projekte/supergeheim/dateien/ (oder wie auch immer
das heißt, könnten ja auch mehrere Ordner sein) können dann mit
umask 002 angelegt werden. Die Gruppe sgleitung (der die Dateien
gehören) darf schreiben, others lesen. Da nur sg bis
/projekte/supergeheim kommt, ist others hier ja die, die in sq
sind.

In der Praxis dürften Norbert und Susi vermutlich alle Projekte
lesen (weil sie QA sind oder sowas), dann könnte man gleich
projekte entsprechend konfigurieren. Na ja, wie auch immer,
meistens kriegt man es irgendwie ganz gut hin. Hat man doch Files
zum Projekt, die nur Peter schreiben, doreen, lutz nur lesen
drüfen (Aufträge etc), kann man meistens ein Verzeichnis
"aufträge" machen, was überhaupt nicht in projekte liegt, und
hier meistens auch nicht hingehört.

Klar gibt es Fälle, da wird das sehr umständlich, aber in der
Praxis kann man meistens damit leben, was man so einfach
hinkriegt. Na ja, sicher gibt's genug Ausnahmen.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.