Thomas Wölfers Baustatik-Blog

Thomas Wölfers Baustatik Blog

Wieso muss man beim installieren von Updates immer wieder administrative Daten eingeben?


Heute kam bei einem Kundengespräch die Frage auf, wieso man beim installieren der Updates für die Baustatik, immer wieder den Namen und das Passwort eines administrativen Kontos eingeben muss - immerhin hätte man das ja einmal bei der Erstinstallation getan. Hätte man da nicht einfach diese Daten irgendwo speichern können, um sie dann bei späteren Installation zu verwenden? Das würde doch die Installation der Updates viel einfacher machen, weil man nicht jedesmal den Administrator zur Hilfe holen müsste.

Interessante Frage, und zwar eine aus der Kategorie, die man am besten mit einer Gegenfrage beantwortet. Die Gegenfrage ist bei Fragen dieser Kategorie immer die gleiche, und zwar wörtlich die gleich. Sie lautet.

Was würde denn passieren, wenn wir das täten?

Das Programm das nach den administativen Rechten fragen würde, wäre ja einfach die Baustatik, und die läuft nunmal (zumindest sollte man sie so betreiben) ohne administrative Rechte. Das tut sie darum, weil der Benutzer der das Programm gestartet hat, sich selbst mit Daten angemeldet hat, die eben keine administativen Rechte haben. Das ist ja der Grund dafür, weshalb nach solchen Daten gefragt werden muss.

Wir haben also ein Programm, das ohne administrative Rechte läuft - und dieses Programm würde nun die Daten eines administrativen Accounts speichern. Und wo würde es diese Daten speichern? Natürlich innerhalb eines Bereiches auf der Festplatte, auf den der Benutzer OHNE administrative Rechte Zugriff hat - denn ansonsten könnte das Programm ja "später", also bei der Installation der Updates, nicht mehr darauf zugreifen.

Effekt: Die Daten eines administrativen Accounts lägen nun plötzlich ungeschützt einfach so auf der Festplatte, und zwar an einer Stelle, auf die JEDES Programm zugreifen kann, das unter dem Account des angemeldeten Benutzers läuft.

Mit anderen Worten: Das administrative Konto wäre plötzlich völlig ungeschützt und kann dann von jeder Schadsoftware die unter dem Benutzeraccount ohne administrative Rechte läuft verwendet werden. Zum Beispiel, um irgendwelche Trojaner oder sonstigen Kram zu installieren - und zwar für ALLE Benutzer auf dem System. [Natürlich ist die Sache nicht ganz so einfach, vom Prinzip her ist das aber völlig korrekt.] 

Mit anderen Worten: Wenn die Baustatik sich die Daten des Administator-Kontos in einer Form merken würde die es erlaubt, spätere Updates ohne einen administrative Account zu installieren, würde das die komplette Sicherheit des Systems aushebeln.

Und das ist der Grund, wieso wir das nicht tun. Und sollte ein anderer Hersteller das tun, dann mag er das vielleicht als "einfachere Bedienbarkeit" verkaufen - in Wirklichkeit handelt es sich aber einfach nur um die Einführung einer massiven Sicherheitslücke.


Vista: Sicherheitswarnung loswerden


Wenn man unter Vista ein Programm startet, das man aus dem Internet heruntergeladen hat, dann bekommt man folgenden Warnhinweis:

Der ist durchaus berechtigt und will darüber aufklären, das der Autor des Programms nicht bekannt ist - was bei runtergeladenen Programmen ja durchaus richtig ist. Die Meldung kommt auch bei späteren Programmstarts - nicht nur beim ersten Mal.

In der Theorie ist es nun so, das man - so man sich seiner Sache wirklich sicher ist - die Option "Vor dem Öffnen dieser ..." ausschaltet: Dann wird man in der Zukunft nicht mehr befragt. Das klappt aber nicht immer: In einigen Fällen kann man die Option so oft ausschalten wie man will - die Frage kommt trotzdem immer wieder.

Grund: Die Datei befindet sich auf der Festplatte in einem "sicheren" Bereich, wie zum Beispiel im Ordner "Programme". Dort hat man aber normalerweise keine Schreibrechte - und darum kann sich Windows die veränderte Option auch nicht melden. Für diesen Fall gibt es verschiedene Workaround. Der meiner Ansicht nach einfachste funktioniert, indem man eine Kommandozeilenfenster als Administrator öffnet, und dann folgendes tut:


Fehlende Icons im Notifizierungsbereich


Bei Windows können laufende Programme kleine Icons im Notifizierungsbereich (Tray) des Task Bar anzeigen. Dort erscheint zum Beispiel auch die Uhrzeit, oder auch Icons, die auf neue eingegangene eMails hinweisen. Auch unsere Software benutzt diesen Bereich und zeigt dort ein rotes D für den TimeServer des Work&Cash Verfahrens an.

Auf das rote D kann man dann mit der rechten Maustaste klicken und die eigenen Zeiteinheiten verwalten.

Nun hatten wir heute einen Kunden, bei dem das rote D nicht länger angezeigt wurde. Der TimeServer lief aber - das war über die Prozesse im TaskManager zu verifizieren. Windows kann so konfiguriert werden, das bestimmte Icons nicht angezeigt werden sollen, das geht über die "Eigenschaften" des Taskbars. Das war aber beim Kunden nicht der Fall. Was mich vor ein Problem stellte, denn von unserer Seite aus gibt es keine Möglichkeit das Icon auszublenden. Das fehlende Icon war also eindeutig entweder auf einen Fehler in der Windows-Installation, oder auf einen Einfluss durch ein Programm eines Drittherstellers zurückzuführen.

Ich begann also eine kleine Internet-Suche und fand auch einige Hinweise: Die waren allerdings sehr schwamming - so, wie das eben so ist, mit Postings aus irgendwelchen Foren. In diesem Fall gab es aber eine ganze Menge an Personen, die eine - wenn auch für mich nicht nachvollziehbare - Lösung bestätigten: Man musste einen bestimmten Dienst abschalten. (Zu finden zum Beispiel hier oder hier.)

Der Zusammenhang zwischen dem Problem und der Lösung ist für mich noch immer nicht nachvollziehbar, hat aber auch unserem Kunden geholfen: Es scheint sich also tatsächlich um eine gangbare Lösung zu handeln. Wenn ein Icon zu einem laufenden Programm im Tray fehlt, und das Icon nicht ausdrücklich ausgeschaltet wurde, dann scheint folgendes zu helfen:

- Öffnen der Computerverwaltung in der Systemsteuerung
- Öffnen des Applets für die "Dienste"
- Den SSPD Discovery Service finden und doppelklicken
- Dann den Dienst zunächst anhalten, und außerdem dauerhaft abschalten
- Zu guter letzt den Rechner neu starten: Die fehlenden Icons sollten nun wieder da sein

Der SSDP - Dienst, der da abgeschaltet wird implementiert das Simple Service Discovery Protocol: Er ist im wesentlichen für das erkennen von Universal Plug & Play Geräten im Netz zuständig. Wenn man solche Geräte nicht hat (und ich kennen eigentlich niemanden, der so ein Gerät hat), dann tut das abschalten auch nicht weiter weh. (Im oben verlinkten Thread gibt es auch eine Lösung für den Fall, das eben doch UPnP Geräte vorliegen.)

Wer mir irgendwer erklären kann, was das eine mit den anderen zu tun hat: Bin für jede Erklärung dankbar - ansonsten handelt es sich eben um eine Lösung, die ich nicht wirklich erklären kann.


Hübsche Graphiken in Vista


Manchen ist es ja nicht so wichtig, ob die Dinge, mit denen sie täglich zu tun haben, hübsch anzusehen sind oder nicht. Solche Menschen meckern dann auch gerne rum, das Vista zu viel "Klicki-Bunti" hätte. Mir geht das anders: Ich mags hübsch. Darum gefällt mir auch einiges in Vista deutlich besser als in XP. So sieht zum Beispiel mein Laufwerks-Ordner in der Darstellung "Große Symbole" aus:

Man kann die Bilder für die Laufwerke übrigens stufenlos noch deutlich größer machen - etwa 4 mal so groß, wie hier abgebildet.


WinRAR und Probleme bei der Installation der Baustatik


Bei WinRAR handelt es sich um ein Kompressionsprogramm, das auch .ZIP-Dateien lesen und dekomprimieren kann. Wer Windows XP oder eine neuere Version von Windows einsetzt, braucht das Programm eigentlich nicht, da diese Windows-Versionen ZIP-Dateien ohne Hilfe einer weiteren Software behandeln können. In einem solchen Fall kann mann in der baustatik_setup.zip einfach auf das "setup.exe" klicken um die Baustatik zu installieren: Die Dateien werden dann "automatisch" im Hintergrund in einen temporären Ordner entpackt, und die Installation erfolgt dann über diesen Ordner. Das geht problemlos, allerdings kann die Installation dann nicht automatisch "repariert" werden, wenn das zu einem späteren Zeitpunkt mal notwendig werden sollte.

Auf Basis eines Gesprächs mit einem Kunden geht das mit WinRAR offenbar nicht so gut: Zumindest im Fall des Kunden war es so, das die Installation zwar gestartet wurde, aber dann letztlich nicht abgeschlossen werden konnte. Statt dessen wurde das fehlen einer Datei mit dem Name rar(...)\data.msi angemeckert. Unser Installationsprogramm enthält keine Datei mit diesem Pfad. Aufgrund des "rar" im Namen vermute ich aber, das es sich um eine von RAR angelegte temporäre Datei handelt - die aber nicht wirklich angelegt wurde. Darum ging die Installation dann schief. Offenbar muss man, wenn man WinRAR zur Behandlung von .ZIP-Dateien verwendet, die Installationsdatei der Baustatik erst in einen separaten Ordner extrahieren und von dort starten, statt sie direkt aus der ZIP-Datei heraus auszuführen.


Logfiles vom Windows Installer


Der Windows Installer ist eine Systemkomponente, die für das installieren von Software gedacht ist. Vermutlich jeder hat schonmal eine Datei mit der Erweiterung .msi gesehen - das sind die Dateien die (u.a.) vom Installer installiert werden. Im Normalfall gibt es zur .msi - Datei auch noch eine "setup.exe": Die braucht man aber nicht unbedingt, denn man kann die MSI-Datei auch "von Hand" installieren. Und besonders wenn bei der Installation ein "unerwarteter" Fehler eintritt muss man das auch.

In einem solchen Fall hilft die Fehlermeldung meist nicht weiter: Alles was man weiss ist, das es einen Fehler gibt - man kennt den genauen Grund aber nicht. Da kommt man aber dran, und zwar, indem man den Installer dazu bringt, ein ausführliches Protokoll des Installationsvorganges anzulegen. Mit diesem Protokoll kann man dann die eigentliche Ursache für den Fehler aufspüren. Um das Protokoll anzulegen geht man wie folgt vor:

- .msi-Datei in einem temporären Ordner (z.b.: c:\temp ) kopieren
- Eingabeaufforderung öffnen und in diesen Ordner wechseln
- Folgende Kommandozeile eingeben: msiexec /i NameDerMsiDatei.msi /L*v PfadZuEinemLogfile

Dabei steht NameDerMsiDatei natürlich für die Msi-Datei (also zum Beispiel data.msi) und PfadZuEinemLofile für den Namen der Protokoll-Datei, also zum Beispiel c:\temp\logfile.txt.