KONZEPT
	Zugriffsrechte

BESCHREIBUNG
	Bei Problemen mit read_file(), write_file(), rm(), write_bytes(),
	write_log(), restore_object(), save_object(), sowie bei auftretenden
	Fehlern "Illegal use of save_object" oder Questobjekten, die einfach
	nicht speichern wollen bzw. nur manchmal nicht, dann sollte man sich
	die Zeit nehmen (!!!) und das hier lesen. Auch das Mysterium, warum
	es immer gerade dann geht, wenn man den Bug einem anderen Magier
	zeigen will und kaum dreht man den Ruecken, bugt es wieder, sollte
	hier etwas entzaubert werden.

ZUGRIFFSRECHTE IM WUNDERLAND
	Es gibt mehrere verschiedene Moeglichkeiten Zugriffsrechte, in einem
	Multi-User-System zu arrangieren. Vor langer langer Zeit hat jemand
	entschieden, dass das Wunderland User-IDs (uid) und effektive User-IDs
	(euid) benutzt. Man koennte darueber streiten, was besser waere, aber
	es ist nun einmal 'goettlicher' Wille gewesen und wir muessen uns dem
	fuegen.	Also sind Zugriffsrechte (Lese- und Schreibrechte) im
	Wunderland objektgebunden und basieren auf User-IDs (uids) aehnlich
	(!) zu einem Unix-Filesystem.

	Fuer die Insider: Der Driver laeuft im 'strict euids mode'.

USER-ID
	Jedes Objekt besitzt eine fest vorgegebene User-ID (als String), die
	vom Master (/secure/master.c) jedem Objekt bzw. jedem File zugeteilt
	wird. Spieler/Magier bekommen immer ihren Namen als UID, ebenso die
	Objekte in den Homeverzeichnissen der Magier in /players. Andere
	Objekte bekommen meist eine vom Master festgelegte UID, die Teile
	des Pfades oder den Regionsnamen oder etwas aehnliches enthaelt.
	Bei der Abenteurergilde beispielsweise: "gilden:abenteurer". Objekte
	in /obj und /std haben die sogenannte Backbone-ID, das heisst, beim
	Clonen solcher Objekte bekommen diese immer die UID des Cloners.
	Wichtig vor allem fuer die Tools in /obj/tools/*. Objekte in /secure
	haben die Root-ID.

	Die UID kann man bei ls -l in der dritten Spalte von links sehen
	oder mit getuid(E) erfragen, aber wie gesagt, der Master legt das
	fest und es kann auch davon abweichen (also ls eine andere Form
	liefern als getuid).

EFFEKTIVE USER-ID
	Die USER-ID allein bewirkt noch keine Lese- oder Schreibrechte. Sie
	legt quasi nur den 'Rahmen' fest. Entscheidend ist vielmehr die
	'effektive USER-ID' (EUID). Diese ist wiederum entweder ein String,
	im Regelfall "NOBODY", theoretisch auch 0. Welche Rechte ein Objekt
	mit einer bestimmten EUID konkret hat, haengt davon ab, welche
	Rechte man dieser gibt. Dazu aber mehr im naechsten Punkt, wichtig
	ist erstmal nur, dass die Zugriffsrechte primaer von der EUID eines
	Objekts abhaengen. (Die Euid kann (normal) immer nur weniger bis
	gleich viel Rechte bieten, wie die Uid das tut. Die Uid ist also
	das Maximum an Rechten, die ein Objekt bekommen kann. Welche es
	wirklich hat regelt ausschliesslich die Euid.)

	Spieler/Magier haben die gleiche EUID wie ihre UID. Also Magier
	Bluelight hat die UID "bluelight" und auch die EUID "bluelight".
	Bei geclonten Objekten aus /obj und /std ist die EUID wiederum
	die UID des Cloners. Clont Bluelight ein /obj/fackel, dann ist
	die EUID der Fackel "bluelight". Nicht verstanden? Nochmal lesen! :)

	Ist die UID eines Objekts gleich der EUID des Cloners, dann bekommt
	das Objekt auch die EUID des Cloners, andernfalls "NOBODY". Zum
	Beispiel hat [/players/gilbert/fackel] die UID "gilbert". Wenn
	Gilbert die Fackel clont, hat die Fackel auch die EUID "gilbert".
	Wenn aber Bluelight die gleiche Fackel clont, hat die Fackel die
	EUID "NOBODY". Das soll nicht heissen, dass Bluelight ein NOBODY
	ist. :-) Wenn aber die Schreibrechte von der EUID abhaengen, dann
	ist es keine gute Idee, zu viele Objekte mit 'maechtigen' EUIDS
	entstehen zu lassen. Etwas kompliziert? Einfach merken: Tools
	gehoeren nicht in das Homeverzeichnis, wenn man halbwegs sicher
	sein will, dass damit nicht zu viel Unfug getrieben wird...

	Wenn man den letzten Abschnitt genau gelesen und verstanden hat,
	dann wird auch das am Anfang genannte Mysterium etwas klarer.
	Ein Magier X schreibt sich (in /players) ein Objekt, was mit
	save_object() arbeitet. Solange er (selbst) das Objekt selbst
	laedt/clont, funktioniert das auch einwandfrei. Magier X freut sich
	tierisch und laesst andere Leute das testen. Doch da bugt es dann
	irgendwann, spaetestens dann, wenn die Tester die Objekte selber
	laden oder clonen. Dann entsteht naemlich ein "NOBODY"-Objekt und
	das kann nunmal NIX. Da die UID des Objekts allenfalls im Homedir
	des Magiers gleich der EUID des Cloners sein kann, sollte dieses
	Problem nur dort auftreten. Wie man das loest, steht im uebernaechs-
	ten Absatz.

	In den Regionenverzeichnissen wird (seit einiger Zeit) die UID
	des Magiers mit einem davorgehangenen 'd:' (fuer [d]omain) gesetzt.
	Objekte in /d/berge/rayone/* bekommen die UID "d:rayone". Das be-
	deutet, die EUID des Cloners kann eigentlich nie mit der UID der
	Objekte dort uebereinstimmen, die Objekte bekommen ergo _immer_ die
	EUID "NOBODY". Sie haben also niemals irgendein Schreibrecht. Will
	man also save_object() oder write_file() etc. benutzen, muss man
	eine EUID setzen, sonst: "Illegal use of save_object" oder es geht
	stillschweigend nicht, weil der Returnwert von write_file()
	geflissentlich ignoriert wird...

	Ein Objekt kann mittels seteuid(E) immer nur die eigene UID als EUID
	setzen. Das sieht dann so aus: seteuid(getuid());. Hab ich da eben
	ein leises AAHA gehoert? Ein Objekt [/d/berge/rayone/obj/bla] hat
	die UID "d:rayone" und EUID "NOBODY", bis es (selbst!) 
	seteuid(getuid()); aufruft, dann hat es auch als EUID "d:rayone".
	(NPCs und Raeume setzen ihre EUID normal immer (!) auf ihre UID,
	hier muss man es also nicht machen!)

	Die wesentlichen Zusammenhaenge zwischen UID und EUID sollten klar
	geworden sein. Wenn doch nicht, dann merk Dir einfach, dass Du 
	seteuid(getuid()) machen MUSST, wenn Du eine Funktion benutzt, die
	etwas schreiben koennen soll. (Siehe Ausnamen oben. Dieser
	Absatz gilt also nur vor (nehmbare) Dinge und eigene Master usw,
	halt alles was weder NPC (Netti, Mnpc) oder Raeum ist.)

LESERECHTE
	Wir handhaben die Leserechte im Wunderland recht (oder eher zu?)
	grosszuegig. Jeder Magier kann schon von Beginn an fast alle Ver-
	zeichnisse einsehen und Files lesen. Verwirklicht wird das durch
	den Master (/secure/master.c), der fast allen EUIDs Leserechte
	auf fast alles gibt. Ein paar Sachen wie die News, Mails, Secure-
	Savefiles und andere 'Kleinigkeiten' werden restriktiver behandelt;
	warum sollte klar sein.

	Der Master ueberprueft also anhand der EUID das Leserecht eines
	Objekts. Um ein paar Luecken (siehe oben) zu stopfen, prueft der
	auch noch etwas mehr, aber dies nur, um Missbrauch zu verhindern.

SCHREIBRECHTE
	Das gleiche gilt grundsaetzlich auch fuer die Schreibrechte. Hier
	sind wir natuerlich nicht so grosszuegig und ich seh auch schon,
	wie Du beim Lesen dieser Zeilen heftig nickst. :-) Nichtsdestotrotz
	das Prinzip ist das gleiche, die EUID spielt die erste Geige, wenn
	es um Schreibrechte geht. Ein Objekt ohne EUID oder mit der EUID
	"NOBODY" hat keinerlei Schreibrechte.
	(Ausnahme save_object() ins selbe Verzeichnis, wo das File auch ist.)

	Grundsaetzlich hat ein Objekt immer dort Schreibrechte, wo dessen
	EUID mit der UID der Files uebereinstimmt. Da ein Magier auch nur
	ein 'Objekt' ist, gilt das natuerlich fuer die genauso. Alle anderen
	Schreibrechte muessen in den 'access_rights.c'-Files vergeben wer-
	den. Die Funktion save_object(E) und ein paar andere werden etwas
	spezieller gehandhabt in einigen Teilen der Lib, aber das ist hier
	nicht so wichtig.

	Magier(-Objekte) haben neben diesen 'Grundrechten' noch ein paar
	weitere, die mal 'grob' aufgelistet werden sollen. Hoehere Level
	schliessen natuerlich die Rechte der niederen jeweils mit ein:

	Magierlevel	| Rechte
	----------------+---------------------------------------------------
	ab Level 10	| + /tmp
			| + Homedir in /players (wenn vorhanden)
			| + Homedir in den Regionen (wenn vorhanden)
			| + Verzeichnisse "alle" oder "common" in einer
			|   Region, wenn Magier dort auch ein Homedir hat.
			| + in den Unterverzeichnissen von /log
	ab Level 30	| + /doc
	ab Level 40	| + gesamte Region (wenn als RM eingetragen)
			| + Leserechte im LORD-Verzeichnis, sowie das Recht
			|   dort FPs an/abzumelden  (nur wenn als RM einge-
			|   tragen)
			| + Recht Skills an-/abzumelden (nur mit Absprache)
	ab Level 50	| + Lese-/Schreibrechte in allen Regionen, Gilden,
			|   Spellbooks, Homedirs und in /p
	ab Level 60	| + Leserechte in ARCH-Verzeichnissen
			| + /global, /save
			| + Recht Homedirs und Regionen anzulegen/loeschen

	Alle anderen Level gibts nur fuers persoenliche Ego, besondere
	Zugriffsrechte ergeben sich daraus nicht! Zusaetzliche Rechte
	koennen, wie bereits erwaehnt, ueber die access_rights.c-Files
	eingeraeumt werden.

SIEHE AUCH
	uids(C), getuid(E), seteuid(E), geteuid(E), save_object(E)