Bits und Bytes (war Re: [php] Berechtigungs System)

[Konstantin Rekk]

On Tuesday 03 February 2004 12:25, Andreas Müller wrote:
> ein Integer Wert für Berechtigungen ist aber ziemlich mächtig! Das
> komplette Berchtigungs von Unix/Linux (xwr) besteht immerhin aus nur
> "3Byte => 24Bit" die auf jedes Element im Verzeichnissbaum gelegt wird,
> Jeweils ein Byte für den User-, ein Byte für die Gruppenberechtigung und
> ein Byte für den Rest. Natürlich kommen noch ein paar kleine ganz Zahl
> Werte dazu um die User- und GroupID auf jedeselement zu setzen ist die
> User- oder GruppenID des Elements nicht der die Element hinterlegt sind
> dann komment die Werten für den Rest zum Zuge.
> User- und Grouprechte werden logisch verknüpft!
> Wenn du dann zum Bsp. SuperAdmin den Gruppen Syslog, Forenadmin,
> Newsadmin zuweist (die Gruppen haben alle Berechtigungen im ihren
> jeweiligen Umfeld) den Admin aber nur lese Rechte als User zuweist kann
> sich der Kerl alles angucken, gibst du ein Schreibrecht hinzu kann er
> zum Beispiel alles veränder (löschen, verschieben, den Text bearbeiten
> etc.) den Executewert nimmst du dann zum Beispiel für das online Stellen
> von News- und Forenartikel.
>
> Dieses System hat zwar schon viele Jahre auf Buckel, ist aber meiner
> Meinung nach immer noch das flexibelste was es gibt, und so lange wie
> Gruppen und die User nicht überhand nehmen auch sehr übersichtlich!
>
> Ich hoffe ich konnte dir mit diesem Beispiel etwas Sorge vor dem "nur"
> 32 Rechten nehmen und zeigen das man mit etwas geschick aus man mit 3
> Berechtigungen pro User und Gruppe und pro Eintrag, oder auch nur
> Bereich sehr viel abdecken durch die logische Verknüpfung abdecken kann.
> Im übrigen Microsoft nimmt für ihres Berechtigungssystem unter NTFS
> (WinNT, Win200, WinXP) fast das gleiche Berechtigungssystem, nur das sie
> x User und x Gruppen auf ein Element zuweisen, was aber in unserem Fall
> und für jedes CMS was ich bisher gesehen habe übertrieben Groß währe im
> Vergleich Kosten/Nutzen.

Genau der Meinung bin ich auch, nur hatte jemand hier von ca. 80 Rechten 
gesprochen...

Bin zwar kein BS-Spezi aber ich denke die Rechte sind in Wirklichkeit mit
12 bit kodiert 4 mal 3 (9 bit für Rechte, 3 special bits).
(siehe auch: http://www.silug.org/lists/silug-discuss/200204/msg00250.html 
oder http://www.linuxfocus.org/English/January1999/article77.html)

in Wirklichkeit ist die Anzahl der Rechte in unix grob gesagt 12xAnzahl der 
Objekte, das Dateisystem unter anderem eine Art Datenbank die areas( dir, 
files) mit Permission in relation bringt, dadurch könnten entstehen  
praktisch
9xAnzahl(Dir)+Anzahl(Files) die ein user haben, was so aber auch nicht stimmt, 
weil
die Gruppensicht dafür sorgt, dass man nicht jedes Object mit jedem user 
kreuzen muss.

 Allerdings sind das immer noch genügend viele ;-)

Ein komplettes Rechtesystem würde sich also auf areas und objecte beziehen und 
diese mit  usern und aktionen kreuzen (multiplizieren), da dies aber zu 
umfangreich ist,
kann man die Objekte hierarchisch in Gruppen ordnen und die Aktionen ebenfalls
(siehe auch permissions in mysql *.*, mydb.*, mydb.matable.select ), sowie 
die user in rollen oder gruppen aufteilen. Die Aktionen kann man ebenfalls 
nach Levels ordnen. Insgesamt ist das Problem aus dem Produkt (Objekte x user 
x Aktionen) eine geeignete Relation (mit zusätzlichen Eigenschaften) 
auszuwählen und die Suche oder Abfragen  für diese über eine Art 
Hash-Abbildung zu optimieren ( bspw. $has_perm = perm-bit | MY_PERM_WRITE ) 
wobei man von den zusätzlichen 
Strukturen bzw. Eigenschaften der Relation profitier kann.

Was ich in Wirklichkeit sagen wollte ist, dass bei komplexeren Systemen man 
nicht mit dem Abspeichern einer 32 bit zahl in der user-tabelle auskommt, um 
das Ganze in den Griff zu bekommen. 

Also wie im Unix-Rechtesystem als DB-Abbild, hier mit dem einfachen 
parent-id-modell (oder eher Windows... da hier keine 
Benutzeranzahleinschränkung durch die Länge der Bit-Folge der user_id 
entsteht, wenn das obige stimmt und die user/group-id wirklich mit in den 24 
bit gespeichert wird):

object(id, parent_id, class, owner_id, group_id, 9 bit-perm) 

... und  natürlich noch der Baum für user bzw.gruppen, und innerhalb der 
Applikation das Wissen über die Aktionen innerhalb der Anwendung.
Ein object kann hier (jetzt im Web-Kontext) eine html-Seite, aber auch nur ein 
Text oder Bild innerhalb der Seite sein, oder aber auch nur ein einzelner 
Link der aktiviert wird oder nicht .... man kann sich da also beliebig 
reinsteigern ;-)

im Kontrast zum ad hoc Modell:

user_perm( user_id, 32-bit-perm) mit meta-info-tabelle über die Bedeutung der 
einzelnen bits bit0-31 ...
oder inherhabl der  Applikation  - define(MY_USER_PERM_DROP_EVERYTHING, 1);

Das ganze kann wirklich umfangreich werden, ich würde so allgemein wie möglich 
entwerfen, aber nur das, was wirklich benötigt wird, programmieren.

Gruß an alle die bis hierher durchgehalten haben =;O)
Konstantin.