UAC oder keine UAC – Das ist hier die Frage

Mit meinem vorherigen Blogeintrag Windows 8 ist Gift für Legacy Code kam auf Twitter eine Diskussion zu Stande, wieso denn unsere Anwendung derart hohe Berechtigungen benötigt und dass der Code doch inzwischen längst neu geschrieben worden sein sollte. Außerdem wurde eingeworfen, was Legacy Code direkt mit der UAC zu tun hätte.

Gemäß der englischen Wikipedia Ausgabe beschreibt Legacy Code unter anderem eine nicht länger unterstützte Technologie. Demzufolge ist Windows XP, als das am weitesten verbreiteten Betriebssystem nach Windows 7 ein Legacy System. Zunächst einmal hat Legacy Code nichts direkt mit der Benutzerkontensteuerung zu tun. Allerdings ist es so, dass Legacy Code in der Regel recht alt ist, weshalb er konsequenterweise eben auch nicht mehr weiterentwickelt wird. Code, welcher z.B. vor .NET entstand, würde ich in jedem Fall als Legacy bezeichnen. Selbst .NET 1.0 und 1.1 würden vermutlich die meisten von uns hier einordnen. Nun ist klar, dass vor beispielsweise 10 Jahren die Coding Conventions noch völlig andere waren. Programmkonfigurationen standen in INI-Dateien im lokalen Ausführungsverzeichnis oder die Registry musste für das ein oder andere Szenario herhalten. Demzufolge ist es vorwiegend Legacy Code, der mit der UAC Probleme macht. Das heißt nicht, dass nicht auch neuer Code nicht Schwächen aufweist, jedoch betrifft es vornehmlich alte Module.

 

Ich schätze, dass mindestens 80% der Anwendungen (z.B. die ERP-Systeme) noch entsprechende Module verwenden. Und das ist eine sehr konservative Schätzung! Holger Schwichtenberg schrieb zu Windows 7, dass noch kein Bestandteil auf .NET basiert. SAP hat nach dem, was ich von Consultants höre, noch teilweise Programmzeilen aus den 70er Jahren. Wie ich aus eigener Erfahrung weiß, ist selbst heute noch für die Datenübertragung im EDI Umfeld primär OFTP v1 im Einsatz, d.h. die Kommunikation zwischen Firmen geht mit einer überwältigenden Mehrheit über ISDN. Das zeigt, dass alte Technologien allgegenwärtig sind. Wer sich damit bisher noch nicht hat rumschlagen müssen, gehört zu den wenigen Glücklichen.

 

Wie gesagt: Nur, weil alte Software im Einsatz ist, heißt dies nicht, dass deshalb automatisch höhere Berechtigungen notwendig sind, doch leider ist das oft der Fall. Nun könnte man noch erörtern, wie es denn sein kann, dass die Codestrukturen noch nicht aktualisiert wurden. Das spielt für mich allerdings kaum eine Rolle, da wir einfach vor diesem Problem stehen.

Aber um der Sache Genüge zu tun: Projekte werden immer noch (nichts von wegen agil) in großen Firmen auf Jahrzehnte geplant, wenn man nach HP geht, läuft deren Strategie sogar auf 75 Jahre (geradezu lächerlich!). Darüber hinaus kann eine IT sich nicht einfach einmal 3-5 (oder länger) Jahre Zeit nehmen und allen alten Code migrieren. Wenn sie das täte, würde die Fachabteilung / Geschäftsleitung vermutlich den Verantwortlichen direkt vor die Tür setzen. Selbst wenn dem nicht so wäre, so käme man der Konkurrenz nicht mehr hinterher und könnte das Produkt gänzlich einstellen.

Frage an die Leser: Wer kam denn bisher gar nicht in die Berührung mit Legacy Code?

Werbung

Windows 8 ist Gift für Legacy Anwendungen

Mit Windows 8 könnte für viele Entwickler das böse Erwachen kommen: Legacy Anwendungen, die höhere Rechte erfordern, können nicht mehr ausgeführt werden. Vergleicht man die zwei Dialoge der Benutzerkontensteuerung von Windows 7 und Windows 8, so erkennt ist kein Unterschied ersichtlich. In beiden Fällen werden die Benachrichtigungen deaktiviert. Leider versäumt es Microsoft darauf hinzuweisen, dass damit die Benutzerkontensteuerung nicht wie in Windows 7 deaktiviert ist. Demzufolge laufen die Anwendungen weiterhin mit niedrigeren Rechten. Technischer Hintergrund ist der Admin Approval Mode (als Teil der UAC), welcher einen Security Token mit einer niedrigen Berechtigungsstufe an alle gestarteten Prozesse hängt. Mehr Informationen liefert Technet. Außerdem möchte ich auf diese Seite hinweisen, die das Thema verständlich und auf den Punkt gebracht erläutert.

Allerdings gibt es zwei Wege die UAC gänzlich abzuschalten: Über die Registry oder Richtlinieneditor (Anleitung). Leider führt das zu neuen Problemen, die sich so manifestieren:

Alle Windows 8 Apps können somit nicht mehr gestartet werden. Lediglich reine Desktopanwendungen funktionieren weiterhin. Der integrierte PDF Reader ist damit wertlos.

Die Theorie von Microsoft, dass alle Anwendungen inzwischen ohne Admin-Recht laufen sollten, ist schön und gut, allerdings ist sie, betrachtet man die Betriebe, eher realitätsfern. Legacy Code greift leider immer noch auf das Programmverzeichnis zu oder muss bei Updates COM-Komponenten in der Registry anmelden. Hier wäre es von Vorteil, wenn Microsoft eine Art Sandbox anbieten würde, in welcher die eigenen Anwendung auf Zugriffe mit erhöhten Berechtigungen analysiert werden kann. Dieses Analyse-Tool sollte dabei z.B. auch alten VB Code unterstützen und bis runter auf Methoden-Ebene die Ergebnisse anzeigen. Ich meine, dass es hierfür eine Lösung gibt, jedoch fällt mir der Name nicht mehr ein. Falls ein Leser helfen kann, so möge er mir das doch bitte schreiben!

Ansonsten bleiben zwei Alternativen. Zum einen müssen die Anwender das Programm übers Kontextmenü als Administrator ausführen, zum anderen wäre ein vorgeschalteter Prozess denkbar, der folgende Funktion übernimmt:

Well, it actually has to request permission in the code, which means a lot of programs are not going to work well with Windows 8 unless they rewrite the code to properly ask for permission.

 

Wer hat seine bestehenden Anwendungen bereits mit Windows 8 getestet und hat ähnliche Schmerzen? Oder können Microsoft Insider den Hintergrund für diese Entscheidung erklären, also den offensichtlichen Sicherheitsaspekt einmal außen vorgelassen. Könnte die Entscheidung im Rahmen der Apps notwendig gewesen sein?