Einfache Einstellungen/Nice Level für nicht-Experten

Hallo Thomas,

also zu dem Thema, wo du mich oben zitiert hast.

Ich habe mir seit einiger Zeit die Frage gestellt, warum hat MS in XP das Besitztum für Objekte, die mit Admin-Rechten (genauer gesagt: von einem Konto, das zur Gruppe der Administratoren gehört, was bei einem Surunner ja temporär der Fall ist) erstellt worden sind, von ehemals (W2k) "Gruppe der Administratoren" auf "Ersteller" geändert und in w2k3 wieder zurück. Dazu gehört die Frage, welche Konsequenzen ergeben sich, wenn man die Einstellung - wie von Surun standardmäßig durchgeführt - ändert?

Nun, zunächst einmal scheint das für Admins keinen Effekt zu haben, denn Besitzer und Admins haben immer Vollzugriff, und infolgedessen spielt es für Admins keine Rolle, ob sie nun auch die Besitzer sind oder nicht. Wenn ein Surunner (gleichbedeutend mit temporär im Zusammenhang mit bestimmten Anwendungen zum Admin erhobenen Benutzer) Dateien erzeugt, muß man 3 Fälle unterscheiden:

Fall 1: Der Surunner installiert ein Programm. In diesem Fall ist es obligatorisch, das der Surunner nicht der Besitzer wird, sonst wäre das ganze Prinzip der unterschiedlichen Rechte im Dateisystem und Registrierung unterminiert. Für diesen Fall ist die von Surun standardmäßig geänderte Besitztum-Option (die XP sich wie w2k und w2k3 verhalten läßt) nicht nur richtig, sondern gar notwendig.

Fall 2: Der Surunner startet ein Programm, daß mit eingeschränkten Rechten nicht (fehlerfrei) funktioniert. Da ich kein Spieler bin, denke ich hierbei vor allem an Programme, die irgendwelche Dokumente (im weitesten Sinne) erstellen. Standardmäßig werden diese wohl irgendwo im eigenen Profilordner gespeichert werden. Hier nun verhält es sich für LUA genauso wie für Admins im gesamten System: Im Profilordner hat der Benutzer Vollzugriff, unabhängig davon, ob er der Besitzer ist oder nicht.[1] Insofern könnte man die Tatsache, daß der Benutzer mit der Surun-Standardeinstellung nicht der Besitzer der Dokumente wird (das ist dann eben auch die Gruppe der Administratoren) noch abtun. Besitz ist aber ein Attribut, daß man im NTFS-System auch für andere Zwecke (zum Beispiel Suche) benutzen kann. Unter Umständen können hier also Probleme entstehen. - Nun besteht die Festplatte aber nicht nur aus den Ordnerzweigen Windows, Programme und "Dokumente und Einstellungen". Wird ein Dokument nun - warum auch immer - an eine andere Stelle außerhalb des eigenen Profils verschoben (zum Beispiel als Backup), so bleibt der Besitzer der verschobenen Datei unverändert. Folge: Der Benutzer kann diese Datei nicht mehr verändern (zum Beispiel nicht durch Überschreiben updaten), obwohl er rein inhaltlich zweifelsfrei das tun können sollte und auch keine Sicherheitsgründe dagegen sprechen. Zumindest kann er das nicht mit den Rechten eines LUA; folglich müßte er einen Dateimanager oder den Windows Explorer als Admin starten. Doch ein als Admin gestarteter Dateimanager ist fast so mächtig wie ein völlig uneingeschränktes System. Will ich als Administrator aber meinen Surunnern nur den privilegierten Start solcher Programme erlauben, bei denen das zur Durchführung der vorgesehenen Aufgaben unvermeidlich ist, kommt ein Dateimanager nicht in Frage. Die einzige vernünftige Lösung besteht also darin, daß der Ersteller auch tatsächlich zum Besitzer wird.

Fall 3 ist eine Verschärfung von Fall 2: Her wird das Dokument sofort in einen Ordner außerhalb des Profils gespeichert. Außer Lesen kann der Benutzer nun überhaupt nichts mehr damit anfangen. Soll die Datei zum Beispiel durch ein anderes Programm, das zur Durchführung keine erweiterten Rechte benötigt, weiter bearbeitet werden, so muß er die Datei zuerst einmal kopieren (die Kopie hat den Ersteller als Besitzer). Nicht nur, daß der Aufwand steigt, sondern es werden auch mehrere Kopien von einer Datei erzeugt, obwohl man aus inhaltlichen Gründen nur eine Version haben möchte und die Verwirrung nach einiger Zeit, welche Datei ist denn nun die "richtige" (was sich nicht immer aus dem Dateidatum beantworten läßt) nimmt zu. Ferner kann ein Benutzer von einer solchen Datei kein Backup nach den Regeln effektiven Backups durchführen, denn dazu gehört, daß das Backup-Programm das Archiv-Attribut beim Sichern löschen darf; aber auch das kann der LUA nicht (es sei denn, man würde mehr oder weniger aufwendig die Rechte nachträglich immer wieder anpassen).

Zurück zu der Frage, warum hat MS bei w2k3 wieder die Version von w2k gewählt? Ich weiß es nicht, habe aber folgende Vermutung: w2k3 ist ein Serverbetriebssystem, das primär nicht dafür konzipiert ist (wenngleich technisch möglich), daß hier Benutzer lokal am Rechner arbeiten. Es wird folglich in den meisten Fällen keine Dokumenten-Dateien geben. Was auf dem Server liegt, sind - soweit lokal erzeugt - Teile des Betriebssystems und Programme; der Rest sind über das Netzwerk zugespielte Daten. XP ist aber ein System, wo Benutzer körperlich vor dem Rechner arbeiten und eben auch Dokumente erstellen. Nach den Vorstellungen von MS - die ich diesbezüglich teile - sollen Anwender sich nicht als Admins anmelden, um mit dem Rechner zu arbeiten; wenn ein Admin aber dennoch einmal Dokumente erstellt (zum Beispiel um bestimmte Konfigurationen zu dokumentieren), so wird aus dem Besitzstatus klar, von wem das stammt. Wie ich schon einmal schrieb, hat MS die Surun-Variante zum temporären Erhöhen eines LUA anscheinend vergessen und nicht bedacht (obwohl das beim Blick in die Unix-Welt klar geworden wäre), daß RunAs alleine nicht ausreicht. Durch dieses Versäumnis ist das Problem mit der Möglichkeit, daß ein (für MS nicht bekannter) Surunner ein Programm installieren und damit dessen Besitzer werden könnte, gar nicht erst in Erwägung gezogen worden. Bei RunAs spielt diese Besitztumsfrage keine Rolle, denn damit wird im Zweifelsfall ein Admin zum Besitzer - unter Sicherheitsaspekten kein Problem.

Wenn ich also einige Postings zuvor geschrieben habe, daß für die dort genannte Gruppe B die aktuelle Besitzoption on Surun bleiben sollte wie sie ist, so habe ich dabei an Leute wie unserem Freund Easter gedacht, aber auch an die Leute, die Kay überhaupt dazu gebracht hatten, Surun zu schreiben; Leute also, bei denen im Zweifelsfall nach der Surun-.Installation das Admin-Konto zum Surunner downgegradet wird. (Kay hatte die "Geschichte" der Entstehung von Surun vor kurzem in einer Antwort an mich kurz skizziert - ich glaube es war im Beta-Forum zur letzten Version 1.1.0.3.) Gruppe A sind nach meiner einfachen Einteilung die Profis, deren Ansprüche höher sind. Hier sehe ich die richtige Vorgehensweise so, daß man Surun dort (und nur dort) einsetzt, wo es um Programme geht, die im eigenen Kontext laufen müssen(!), für andere Aufgaben (Installation, Systempflege) ist RunAs (oder von mir eingesetzt: WinSUDO) der richtige Weg. Wenn man das richtig trennt, braucht man die Standardeinstellung von XP bezüglich des Besitzes der von Admins erzeugten Objekte nicht zu trennen und erspart sich unter Umständen eine Menge Probleme, die daraus folgen.


P.S. Die oben beschriebenen Gedankengänge sind das Ergebnis längerer Überlegungen und Tests. Ich habe versucht, meine Schlußfolgerungen durch die Beschreibungen anderer zu überprüfen, doch ich habe dazu im Internet nichts gefunden; auch der dir ja auch bekannte Blog von Margosis tut das Thema recht lapidar ab und geht auf die Aspekte und Konsequenzen im Einzelnen nicht ein. Ich wäre also aus diesem Grund für andere Meinungen - auch gegenteilige - dankbar, weil sie mir die Gelegenheit gegebene würde, meine Überlegungen entweder zu korrigieren oder zu bestätigen beziehungsweise zu verfeinern.

[Fußnote 1]: Das kann aber auch schon mal versagen: Verschiebt(!) ein Admin eine eigene Datei in das Profil des Benutzers, so habe ich schon wiederholt erlebt, daß der Benutzer nicht den Vollzugriff hatte, also Handarbeit an den Rechten erforderlich wurde.

Da sind wir doch sehr nahe beieinander. Ich hatte die Gruppierung ganz bewußt sehr einfach gehalten, weil ich zwar in der Lage wäre, mir noch die eine oder andere Gruppe auszudenken, aber inwieweit diese zusätzlichen Gruppen dann im richtigen Leben auch vorkommen und für Surun benötigt werden, ist eine andere Frage. Wenn es sich zeigt, daß man mehr Gruppen benötigt, kann man sie immer noch definieren, anstatt im Vorfeld sich kunstvolle Gruppen auszudenken und anschließend festzustellen, daß die Überlegungen für die Katz waren.

In einem Punkt bin ich nicht ganz deiner Meinung: Die Option, wem die Warnung bezüglich leerer Paßwörter angezeigt werden soll, habe ich bewußt für den nice level vorgeschlagen, weil ich mir vorstellen kann, daß der eine andere der Gruppe B das (warum auch immer) nicht ändern will, auf die Dauer diese Warnung dann aber nervt. Die Warnung für Gruppe B von vorneherein auszuschalten halte ich nun allerdings für den ganz falschen Weg (ich war ja wesentlich daran beteiligt, daß Surun die Warnung anzeigt). Natürlich würde für die Gruppe B ein einfacher Ein-/Ausschalter wahrscheinlich reichen; ich wollte aber die Sache auch für dich so einfach wie möglich halten und daraus folgte meine Idee, diese Option auch im nice level so wie sie ist anzuzeigen.

Was die Namensgebung für die Hooks anbetrifft (insbesondere für Gruppe B und insbesondere alle nicht-englisch-kundigen Benutzer ist Hook etwas nicht wirklich faßbares (Gab es da nicht einmal einen Film namens Captain Hook?), wie wäre es denn mit etwas wie diesem: "Automatische Erkennung, wenn ein Programm erweiterte Rechte benötigt"?