Getting Started: Administrative Rechte nur bei Bedarf
In meinem letzten Post hatte ich bereits angekündigt, über meine Erfahrungen als Nicht-Admin (Was für ein Wort..., klingt aber besser als "Eingeschränkter Benutzer" :-)) zu bloggen. Es wird Zeit, daß ich meine Drohung wahrmache.
Übrigens war ich nicht immer so einsichtig... Früher habe auch ich mich im Gefühl der Macht gesonnt und jeden Hinweis auf die Berechtigungslage in anderen Systemen mit dem Hinweis beantwortet, ich könne als Entwickler nunmal nicht auf administrative Rechte verzichten. Das ist im Grunde immer noch so, man benötigt für manche Aufgaben nun einmal die Kontrolle über das System. Programmierung zählt aber sicherlich nicht zu diesen Aufgaben und in den Fällen akuten Rechtenotstands kann man sich seit einiger Zeit sehr gut vorübergehend zum Administrator "aufschwingen".
Wofür benötige ich eigentlich Administratorrechte?
Nun ja, z.B. immer dann, wenn Aktionen anstehen, die mehrere Benutzer bzw. das Gesamtsystem betreffen. Im Falle eines Setups etwa ist es notwendig auf das zentrale Programmverzeichnis zuzugreifen um die Binaries abzulegen. Ggf. müssen COM Komponenten registriert werden usw. Das alles sind Vorgänge, die das Gesamtsystem betreffen, ergo: Adminrechte. Es gilt die goldene Regel, daß ein Benutzer eigentlich nur auf seine eigenen Daten Einfluß nehmen kann. Sprich: Sein Profil unter "Dokumente und Einstellungen" steht im zur Verfügung, seine Benutzerdaten, in der Registry der Schlüssel HKEY_CURRENT_USER.
Neben diesen grundlegenden Zugriffsrechten gibt es auch besondere APIs, die nicht als "Normalsterblicher" verwendet werden dürfen. Ein Beispiel ist die API mit der in der Internet Connection Firewall Ports freigeschaltet werden können. Ein Setup soll das können, schließlich benötigt das installierte Programm womöglich offene Ports. Ein vom User versehentlich gestarteter Trojaner sollte allerdings tunlichst abgewiesen werden...
Apropos Installation: Der Windows Installer kennt übrigens die Möglichkeit, bei Installationen im Netzwerk einen sogenannten "Elevated Install" durchzuführen. Der Netzwerk-Administrator kann also dem Setup-Programm die Möglichkeit einräumen, sich vorübergehend zum Administrator zu befördern...
Nichts zu Schreiben hat der Benutzer im Windows-Verzeichnis, im Programmverzeichnis oder im Rest der Registry... Im Grunde habe ich jetzt auch schon die zwei Kardinalsfehler der meisten Anwendungen angedeutet: Die Registry und das Programmverzeichnis sind Ziel besonders vieler Speicheraktionen. Z.B. versuchen viele Applikationen ihre temporären Daten im Ausführungspfad abzulegen, sprich im Programmverzeichnis. Ganz nach dem Satz "Hier bin ich Porgramm, hier darf ich sein." werden oft Datenbanken, Temporärdateien etc. abgelegt. Damit aber ein durch den User gestartetes Programm keine Binaries verändern kann ist dieses Verzeichnis nur für lesenden Zugriff freigeschaltet: Es kommt also zu einer Access Violation. Wo gehören die Daten statt dessen hin? Ins Profil unter "Dokumente und Einstellungen\Benutzer".
Im Alltag eines Programmierers kommt es gelegentlich vor, daß er Programme installiert, Server administriert oder auf das Gesamtsystem konfiguratorisch zugreifen will. Wie kann er jetzt vorgehen wenn er als "normaler" Benutzer unterwegs ist? Hier ein paar Anregungen:
- Seit Windows 2000 gibt es im Kontextmenü bei Klick auf eine EXE-Datei einen Eintrag "Ausführen als...". Damit ist es möglich, einen anderen Benutzeraccount, z.B. den lokalen Administrator, anzugeben und eine Applikation in diesem Kontext zu starten. Das bietet sich natürlich für Setup.exe an, aber auch eine wiederspenstige Applikation kann theoretisch auf diese Weise gestartet werden. Jetzt hat man wahrscheinlich oft wenig Lust darauf, ständig ein Paßwort einzutippen. Deswegen habe ich mir in den Anfangstagen meiner Non-Admin-Zeit einfach damit beholfen, irgendwann einmalig eine Instanz der cmd.exe als Administrator zu öffnen und alles was ich vorübergehend als Admin ausführen wollte per Drag&Drop auf dieses Fenster zu ziehen. Ein abschließendes "Enter" und die Applikation startet als Admin :)
Kleiner Tipp am Rande: Um Verwirrung zu vermeiden bietet es sich an, für das Admin-CMD andere Farben einzustellen, so ist sofort erkennbar über welche Rechte eine Shell verfügt.
- Die Funktionalität "Ausführen als..." läßt sich auch über das Kommando "runas" erreichen. Beispiel für den Start eines Prozesses als Administrator:
runas /user:Administrator cmd.exe
Diese Zeile kann man natürlich auch in eine Verknüpfung einfügen (Rechtsklick auf die Verknüpfung > Eigenschaften)
- Ein Problem stellen jetzt unerwarteterweise die verschiedenen Programme in der Systemsteuerung dar. Leider handelt es sich um keine Applikationen im eigentlichen Sinn sondern um Dateien mit den Endungen CPL (für Control Panel) bzw. MSC. Wie starte ich nun solche? Es hilft zu wissen, daß man die CPLs und MSCs dieser Welt auch von der Kommandozeile starten kann, eine beherzte Eingabe von compmgmt.msc öffnet also die Computer Management Console. Ein Alternativweg ist, den Internet Explorer als Administrator zu starten und in der Adressleiste "Systemsteuerung" anzugeben. (Achtung: Damit das funktioniert muß der Explorer so konfiguriert werden, daß jede Instanz in einem eigenen Prozeß betrieben wird: Windows Explorer>Extras>Ordneroptionen>Ansicht) So kann man per Klick die Applets entsprechend starten. Eine dritte Methode ist, einmalig auf der Platte nach den CPL-Applets zu suchen und sie als Verknüpfung in irgendeinem Verzeichnis abzulegen. Jetzt funktioniert wieder die Drag&Drop-Methode.
Die vielleicht schönste Methode ist ein kleiner Eingriff in die Kommandozeilen der eben angelegten Verknüpfungen, so daß man bei jedem Start nach dem Admin-Paßwort gefragt wird, z.B.:
%WINDIR%\system32\runas.exe /user:Administrator "appwiz.cpl"
bzw.
C:\WINDOWS\system32\runas.exe /profile /user:Administrator "mmc %windir%\System32\perfmon.msc"
- Wofür benötigt ein Programmierer meist noch Admin-Rechte?
Für COM Interop oder Enterprise Components evtl. Diese beiden speziellen Komponententypen benötigen das Recht, in HKEY_CLASSES_ROOT Einträge zu machen. Wenn oft derartige Applikationen geschrieben werden, hilft es, mit Regedit in besagtem Registryschlüssel die Berechtigungen zu ändern.
Nicht unbedingt Admin-Rechte sind übrigens zu Verwaltung des SQL Servers notwendig. Der läßt sich nämlich ohne weiteres so konfigurieren, daß er entweder in einem anderem Account als dem Systemaccount unterwegs ist (und was läge näher als ihn im eigenen Account zu betreiben) oder alternativ den entsprechenden Windows-Nutzer als Datenbank-Admin zu akzeptieren.
- Ein Problem sei auch nicht verschwiegen: Das Debugging in ASP.NET Applikationen. In einem anderen Blog-Eintrag werde ich darauf ein wenig genauer eingehen, fürs erste beschreibt der Artikel unter http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/tchDevelopingSoftwareInVisualStudioNETWithNon-AdministrativePrivileges.asp wie man sich hier helfen kann...
So... Das war also mein erster Non-Admin-Post :)
Nächstes mal werde ich darüber schreiben, wie man bei bockigen Applikationen herausfindet, woran es liegen könnte und sich hilft ohne das Ding gleich zum Admin zu befördern. Außerdem schauen wir uns dann den RunAs-Befehl noch genauer an, der noch mehr kann als nur die oben beschriebenen Funktionen... Inzwischen freue ich mich auf Euer Feedback!
