6. Technische Informationen zur ACL - Verwaltung Datei: /secure/master/acl.inc Zielgruppe: Admins und interessierte Goetter. DATEN: ~~~~~ Alle ACLs werden in einem grossen Mapping verwaltet, Variablenname ACL. Jeder Mappingeintrag entspricht einem kompletten Verzeichnis. Ausser den Rechten, die fuer dieses Verzeichnis vergeben werden, enthaelt er Verweise auf Eintraege fuer Unterverzeichnisse, die wiederum eigenen Mappingeintraegen entsprechen. ACL[0] entspricht dabei / (root). Jeder einzelne Mappingeintrag besteht aus einem Array, welches wiederum aus Arrays besteht. Diese Arrays bestehen aus 2 oder 3 Elementen. - Der erste Eintrag ist der Dateiname, - der zweite Eintrag ist die dazugehoerige ACL - Liste, die ACL - Liste besteht aus zweielementigen Arrays, dessen erstes Element angibt, fuer wen die ACL-Eintraege gelten, das zweite Element gibt an, welche Zugriffsrechte die Leute haben sollen, - der dritte Eintrag existiert, wenn es Unterverzeichnisse dieses Verzeichnisses gibt, zu denen es ACLs gibt. Diese Zahl x gibt an, welcher ACL[x] - Eintrag die Rechte dieses Unterverzeichnisses beinhaltet. Umstaendlich beschrieben? Hmmm, ok, machen wir ein Beispiel. ACL[0] (root): ({({"d",0,1}),({"z",0,3})}) ACL[1] (/d): ({({"Vaniorh",({({"Vaniorh:DL",63}),({"Vaniorh:DH",62})}),2})}) ACL[2] (/d/Vaniorh): ({({"sissi",({({"sissi",62})})}), ({"mozart",({({"mozart",62})}),5})}) ACL[3] (/z): ({({"Gilden",({({"Gilden",63})}),4})}) ACL[4] (/z/Gilden): ({({"Sehergilde",({({"Gilden:Sehergilde",62})})})}) ACL[5] (/d/Vaniorh/mozart): ({({"theater",0,6})}) ACL[6] (/d/Vaniorh/mozart/theater): ({({"db",0,7})}) ACL[7] (/d/Vaniorh/mozart/theater/db): ({({"emma",({({"/d/Vaniorh/mozart/theater/npc/emma",192})})})}) Beispiel zu kompliziert? Jaja, ich erklaers: Nun, ACL[0] ist relativ einfach, im / - Verzeichnis gibt es die Verzeichnisse /d und /z. Weder fuer /d noch fuer /z gibts ACLs. Die ACLs fuer die Unterverzeichnisse stehen in ACL[1], die fuer /z stehen in ACL[3]. ACL[1] sind die ACLs fuer /d. /d hat das Unterverichnis Vaniorh, hierfuer gibts nun erstmalig eine ACL - Liste: ({({"Vaniorh:DL",63}),({"Vaniorh:DH",62})}) Die Gruppe Vaniorh:DL hat die Rechte 63, die Gruppe Vaniorh:DH hat die Rechte 62. 63 ergibt sich (siehe /sys/acl.inc) aus: ACL_ADMIN | ACL_WRITE | ACL_CREATE | ACL_REMOVE | ACL_MKDIR | ACL_RMDIR Den DHs fehlt das Recht ACL_ADMIN. Fuer die einzelnen ACLs siehe Beschreibung der ACLs. ACL[2] fuer /d/Vaniorh: ({({"sissi",({({"sissi",62})})}), ({"mozart",({({"mozart",62})}),5})}) Im Verzeichnis "sissi" hat "sissi" die Rechte 62. Weitere Rechte unterhalb von /d/Vaniorh/sissi gibt es nicht. Bei Mozart ist das anders: Unterhalb des Verzeichnisses "/d/Vaniorh/mozart" gibt es noch weitere, die sind laut unterem Eintrag in ACL[5] zu finden. Verfolgt man das weiter, so findet man schliesslich in ACL[7] die Rechte fuer /d/Vaniorh/mozart/theater/db: ACL[7] (/d/Vaniorh/mozart/theater/db): ({({"emma",({({"/d/Vaniorh/mozart/theater/npc/emma",192})})})}) Dort hat auf die Datei "emma" die Datei "/d/Vaniorh/mozart/theater/npc/emma" die Rechte 192 (das sind save- und restore-object). Die anderen obigen ACLs duerften nun klar sein: Im Verzeichnis /z/Gilden hat die Gruppe "Gilden" das Recht 63. Weiter gehts in ACL[4], dort findet man, dass die Gruppe "Gilden:Sehergilde" das Recht 62 im Verzeichnis /z/Gilden/Sehergilde hat: ACL[3] (/z): ({({"Gilden",({({"Gilden",63})}),4})}) ACL[4] (/z/Gilden): ({({"Sehergilde",({({"Gilden:Sehergilde",62})})})}) FUNKTIONEN: ~~~~~~~~~~ Die Funktion add_acl_entry fuegt einen neuen ACL-Eintrag hinzu. Dabei wird (natuerlich) ueberprueft, ob der this interactive das ueberhaupt darf. Dazu muss der this interactive auf dem Pfad dahin, wo die ACLs gesetzt werden sollen, das ACL_ADMIN Recht haben (also entweder ausdruecklich selbst bekommen oder aber in einer Gruppe sein, die das darf). Ausser save object und restore object werden alle Rechte an Goetter oder Gruppen vergeben, bei Goettern wird ueberprueft, ob sie Goetter sind, bei Gruppen, ob sie existieren. Wichtig ist hierbei Gross / kleinschreibung; Goetter muessen klein geschrieben werden, Gruppen gross. Hier werden Goetter automatisch kleingeschrieben, der Gruppenmaster (siehe dort) erlaubt nur grossgeschriebene Gruppen. Die ACL-Rechte restore- und save object koennen nur an Dateien vergeben werden (die existieren muessen). Die Funktion delete_acl_entry entfernt ACL-Eintraege wieder. Dabei fallen die meisten Ueberpruefungen einfach weg, denn um ACLs zu entfernen, genuegt es, zu ueberpruefen, ob sie existieren. Will man fuer eine nicht existierende Gruppe ACLs entfernen, so kann das gar nicht gehen, weil man fuer eine nicht existierende Gruppe die niemals zuvor hat setzen koennen. Hat eine Gruppe hingegen lediglich aufgehoert, zu existieren, so muss man natuerlich diese ACLs loeschen koennen. Die Funktion dump_acl_entries und Hilfsfunktionen zeigen die ACLs nun an, und gehen dabei eben auch rekursiv in Unterverzeichnisse. Die Funktion query_access ist nun die Schnittstelle fuer valid_write, hier wird ganz einfach geprueft, ob (Wizard oder eine Datei im Falle von save/restore-Object) auf eine Datei / ein Verzeichnis ganz bestimmte Zugriffsrechte besitzt. int query_access(string *pfad, string wizorfile, int aclmask) Auffallen hierbei mag, dass der Pfad bereits als Stringarray uebergeben wird, das liegt daran, dass valid_write dies bereits so vorliegen hat, also verwende ichs hier auch so. Fuer Debug - Zwecke gibts noch eine Funktion query_acl_dump, die naja, das ACL - Mapping eben so, wie es ist, "dumpt".