Martin Richter – Seite 52

Vista auf Virtual PC und Multi-Session CDs

Ich habe auf meinen Entwicklungsrechner (XP SP2 DualCore 2GB Raid1 Controller etc.) für einige Tests von Installationsroutinen einen Satz von verschiedenen Virtual PC Images. Darunter auch ein Image für Vista.

Nun hatte ich eine Multi Session CD erstellt und nachträglich noch einige neuere Dateien in einer zweiten Session darauf gebrannt. CD in Virtual PC freigegeben, Dateien kopiert und… 😯 was sehen meine müden Entwickleraugen: Alle Dateien sind alt, oder genauer, alle Dateien sind von der ersten CD-Session. Die Dateien der zweiten Sessin werden nicht angezeigt.

CD auf dem XP-Host kontrolliert, alle Dateien OK. Nun scheinbar kommt Virtual PC nicht mit Multi-Session CDs klar. Ärgerlich und dazu habe ich selbst bei längerem googeln nicht einen einzigen Hinweis auf dieses Problem gefunden.
Wahrscheinlich habe ich die offensichtliche Readme.txt und KnownBug-List wieder mal übersehen.

UAC und CreateNamedPipe mit lpSecurityAttributes==NULL

Das Leben steckt einfach voller Überraschungen. Da hat man einen Service der im LocalSystem Account läuft. Mit diesem Service wird über Named Pipes kommuniziert.

Das Programm, das diesen Service steuert soll nur für Administratoren verfügbar sein und greift lesend und schreibend auf diese Pipe zu. Der Admin nutzt dieses Programm oft, muss man dazu sagen.

In der Vergangenheit war da nicht viel zu tun. Einfach lpSecurityAttributes auf NULL setzen und OK. Der Admin hat dann einfach das Steuerungsprogramm gestartet und war glücklich.
Nun unter Vista läuft aber das Steuerungsprogramm nicht mehr mit administrativen Privilegien.

Ist das Programm nicht Vista aware (also hat kein Trustinfo Manifest), dann hat man keinen Zugriff auf die Pipe. Den in diesem Fall wird der Admin Token ausgefiltert!
Ist es Vista aware und man setzt asInvoker als Trustinfo, dann hat man auch keinen Zugriff. Logo.
Nur requireAdministrator führt zum gewünschten Ziel. Natürlich wieder mit der (manchmal) lästigen Meldung für ein Programm das häufig benutzt wird.

—
❗ Also liebe Programmierer Gemeinde! Bitte die SECURITY_ATTRIBUTES richtig ausfüllen mit einer DACL die eben nicht mehr nur den lokalen Admin enthält. Diese bei CreateNamedPipe verwenden und dann kann das Programm auch normal mit asInvoker gestartet werden.

Ach ja! Und ehe ich es vergessen ein NULL DACL ist hier nicht im Sinne des Erfinders… 🙂

😐 Insgesamt ärgerlich:
Man möchte es dem Benutzer möglichst einfach machen Programme zu nutzen. Der Vista-Admin-Privileg Dialog stört da manchmal (nicht immer). Also was macht man? Man setzt die Rechte für die Names Pipes und andere Objekte dieser Welt herunter, weil der Admin Token eben nicht mehr Bestandteil der Rechte ist für Programme die mit asInvoker gestartet werden.
Die Folge: Die Programme werden mit weniger Sicherheitsschranken gebaut, als zuvor.
War das im Sinne des Erfinders?

BTW: Da man sich mittlerweile schon blind angewöhnt hat, diesen Dialog zu bestätigen kann man sich fragen ob da noch ein Sicherheitsaspekt verbleibt, weil keiner mehr liest, welches Programm eigentlich administrative Rechte haben will.

Beim Entpacken von ZIP-Dateien setzt Vista manchmal das aktuelle Datum

Ich hatte gestern den neuesten High Definition Treiber von Realtek für meinen Laptop herunter geladen. Ich entpacke die ZIP-Datei und arbeite noch etwas weiter. Irgendwann schaue ich mir die entpackten Daten an und staune nicht schlecht. 😯

Boah, ich war wohl der erste der diesen Treiber herunter geladen hat, den die Uhrzeit aller Dateien ist gerade mal 5 Minuten her.

😕 Hmmm… Alle Dateien gelöscht. Das ganze nochmal. Wieder aktuelle Uhrzeit. Wie das?

Nun des Rätsels Lösung scheint ein kleiner Bug zu sein.
Die ZIP-Datei die man aus dem Internet heruntergeladen hat bekommt in einem Stream eine Info, die dafür sorgt das Dateien später beim Ausführen warnen. Diese Info kann man sich auch in den Datei Eigenschaften ansehen.
Da steht dann unten im Eigenschaftsdialog: „Diese Datei stammt von einem anderen Computer. Der Zugriff wurde aus Sicherheitsgründen evtl. geblockt.“ (Dämliche Übersetzung! Wieso wurde?)

Daneben finden wir einen netten Schalter Zulassen. Klickt man ihn, dann wird diese Zusatzinfo aus der Datei entfernt. Entpackt man nun die Datei, dann haben die Dateien auch das Datum, das auch beim Packvorgang gesetzt war und auch beim Anzeigen der Daten im ZIP-Verzeichnis zu sehen ist.

Scheinbar wird beim setzen dieser Zusatz-Sicherheits-Infos auch das ursprüngliche Datum vernichtet… ❗

UAC Trustinfo Manifest in ein VC-2005 SP1 Projekt einfügen

An sich ist die Sache ganz einfach. Man erzeugt eine Manifest-Datei z.B. mit dem Namen Trustinfo.manifest, die nur den entsprechenden <trustinfo> Block enthält (und nicht mehr). Um die anderen Manifest Daten für CRT und COMCTL32 v6.0 kümmert man sich erstmal nicht, das soll ja MT.EXE und der Linker machen. Diese Datei fügt man in das Projekt ein. VS erkennt die Endung und der Manifest-Compiler soll diese Datei nun mit den anderen Manifest Daten mischen und das finale Manifest erzeugen.
Man wirft den Compiler an und… 🙄 … erhält die Fehlermeldung:
.\TrustInfo.manifest : manifest authoring warning 81010002: Unrecognized Element „requestedPrivileges“ in namespace „urn:schemas-microsoft-com:asm.v3“.

Entsprechende Recherche ergab, dass nur die MT.EXE aus dem Vista SDK dieses Manifest korrekt einmischt. Die funktionierende MT.EXE hat es nicht in das 2005 SP1 gepackt 🙁 .

OK also Vista SDK herunterladen installieren. MT.EXE ansehen und… 🙄
Die MT.EXE aus 2005 SP1 ist vom 2006-12-02 07:17,
die MT.EXE aus dem Vista SDK ist vom 2006-10-19 14:52,
beide haben eine Größe von 727.552 Bytes und haben die gleiche Versionsnummer 5.2.3790.2075. Es ist nicht zu fassen.

OK packen wir also trotzdem die MT.EXE aus dem Vista SDK in das Verzeichnis C:\Program Files\Microsoft Visual Studio 8\VC\bin

Nun kompilieren wir das Projekt noch einmal und nun…
wunderbar, das Projekt kompiliert wie erwartet. Das Manifest wird eingefügt. Die erzeugte EXE hat alle entsprechenden Manifeste eingebettet.

Wen es interessiert, die Bug-Meldung bzgl. der Versionsnummer ist hier zu finden:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=258108

Es sei noch angemerkt: Mein Testrechner ist ein Vista-Ultimate Laptop. Installiert war auch das VS-2005 SP1 Beta für Vista. Auch diese Version enthält keine kompatible MT.EXE!
Danke Jochen für den Hinweis!

Notwendigkeit von Manifesten für DLL’s mit VC-2005

Durch eine Anfrage in meiner Lieblingsgruppe microsoft.public.de.vc bin ich auf folgende interessante Frage gestoßen: Benötigt eine DLL die mit VC-2005 erzeugt wurde ein Manifest?

Nun wie viele Antworten im Leben lässt sich dies nicht eindeutig mit Ja oder Nein beantworten.

Nein! Es wird kein Manifest benötigt, wenn die CRT statisch gelinkt wird. In diesem Fall wird auch kein Manifest benötigt zumindest nicht für die CRT, was nicht heißt, dass nicht auch andere Assemblies per Manifest angebunden werden müssen.

Nein! Wenn die EXE-Datei bereits über ein Manifest verfügt und eine CRT-DLL mit gleichem Namen lädt, hier also z.B. die MSVCR80.DLL. In diesem Fall kann man sich ein Manifest sparen. Es kann aber hier spannend werden, weil die entsprechende DLL natürlich so nicht beeinflussen kann dir 8.0 CRT als SP1 oder RTM zu nutzen. Aber vermutlich ist das sowieso egal.

Ja! Die DLL benötigt ein Manifest, wenn ein beliebiges Programm die DLL nutzt. Zum Beispiel eines, das die CRT statisch linkt, oder das mit einer älteren VC Version erzeugt wurde. In diesem Fall muss die DLL zwingend ein Manifest haben. Und jetzt wird es noch strenger. Wird die DLL per LoadLibrary geladen, dann muss dieses Manifest sogar embedded sein! 🙄
Externe Manifeste bei DLLs werden nur beim impliziten Laden berücksichtigt. Wird eine DLL mit LoadLibrary geladen, dann werden nur eingebette Manifeste berücksichtigt.

❗ Falle: Hat die DLL kein Manifest wird immer garantiert, dass die CRT Version von EXE und DLL passen. Man kann also gefahrlos Speicher in der DLL allozieren und in der EXE freigeben und umgekehrt. Oder eben auch CRT Objekte austauschen. Nutzt die DLL ein eigenes Manifest besteht die Möglichekit, dass EXE und DLL eine unterschiedliche CRT verwenden! Und noch spannender wird es wenn eine EXE mit CRTx eine DLL1 benutzt die per Manifest CRTy verwendet und diese nun eine DLL ohne Manifest lädt… Ja es wird die CRT der EXE verwendet…

Ja ja. Wir haben dank der Manifeste nun keine DLL Hölle mehr. Wir haben eine Manifest Hölle 😀

Meine Empfehlung daher:

Wenn es eigenständige kleine Module sind, dann statisch gegen die CRT linken.
Ansonsten immer ein Manifest einbetten, wenn die DLL eigenständig genutzt wird!
Wird die DLL im Kontext einer bestimmten EXE(s) Datei verwendet, sollte nur die EXE(s) ein Manifest haben.
In jedem Fall darauf achten, dass gleiche CRT Versionen verwendet werden. RTM, SP1 und irgendwann wahrscheinlich SP2 werden hier Konflikte möglich machen.
MFC Extension DLLs müssen zwingend mit der selben MFC Version (RTM oder SP1) verwendet werden!

Stoff zum weiterlesen:
Isolated Applications and Side-by-side Assemblies

Besonders lesenswert hier der Beitrag von Nicola Dudar:
How to Debug ‚The System cannot Execute the specified program‘ message

Der Tod der Power User…

Nein, es ist kein neuer Horror-Thriller im Kino. Und wir beklagen auch nicht den tragischen Tod einer aktiven Gruppe von Nutzern meiner Software.

Die Gruppe Hauptbenutzer/Power User habe ich gerne auf benutzt um erweiterte Rechte für Entwickler zu geben. Ein Entwickler war damit eben kein Administrator, aber zumindest hatte er Schreibzugriff auf HKEY_LOCAL_MACHINE oder eben auch auf C:\Programme.
Installationen waren damit dann auch kein Problem. Auch zu Hause habe ich meinen Kiddies auch gerne dieser Gruppe zugeordnet. Admin’s waren sie dann keine, aber sie hatten weitgehende Freiheiten.

Wir finden die Hauptbenutzer/Poweruser Gruppe zwar noch in der Benutzer- und Gruppenverwaltung mit dem Kommentar: „Hauptbenutzer sind eingeschlossen aus Gründen der Rückwärtskompatibilität, sie besitzen eingeschränkte administrative Rechte“! Aber das stimmt nicht!

Die Hauptbenutzer/Poweruser Gruppe ist endgültig aus allen Vorgaben in Vista verschwunden.
In den Benutzerrechten für die Registry und C:\Programme finden sich keine vorgefertigten Einträge mehr. Einen Benutzer zum Power User zu machen hat keinen Effekt mehr. Ja schlimmer noch, ein Hauptbenutzer ist nun nicht mal mehr mit Rechten der Gruppe Benutzer ausgestattet.
Wenn, müsste eben selber Hand anlegen. Aber wer will das schon, also machen wir alle ehemaligen Hauptbenutzer zu Administratoren… ob das wohl der Weisheit letzter Schluss ist 😉

Die Power User fristeten ja sowieso schon immer ein nur begrenzt unterstütztes Dasein. Ich hatte mich schon immer geärgert, dass sie nicht automatisch über die Domänen verwaltbar waren. Hier gibt es eben nur Unterstützung für Domänen-Admins, Domänen-Benutzer, Authenifizierte Benutzer etc.

Nun denn… lasst uns trauern, jetzt haben Sie alle unter Vista das Zeitliche gesegnet.

Der VirtualStore und seine Schattenseiten

Es ist ja bekannt, dass Programme, die nicht mit einem entsprechenden Trustinfo Manifest ausgestattet sind, unter Vista besonders behandelt werden. Werden diese Programme nicht im administrativen Rechten ausgeführt werden alle Zugriffe auf das Verzeichne C:\Program Files und auf HKEY_LOCAL_MACHINE\Software in der Registry umgeleitet.

Ein Registry Zugriff landet dann in HKEY_CURRENT_USER auf HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE. Ein Dateizugriff auf C:\Program Files wird umgeleitet nach C:\Users\Username\AppData\Local\VirtualStore\Program Files.

Was passiert aber nun, wenn der Administrator nun tatsächlich die „richtigen“ Daten in HKLM und C:\Program Files ändert UND es existieren bereits entsprechende Daten im VirtualStore?

Die Antwort ist logisch! Eine Änderung der Daten bleibt ohne Wirkung! Denn die Daten aus dem VirtualStore werden hier mit Vorrang behandelt. Sonst macht das ganze ja keinen Sinn, denn der VirtualStore soll ja scheinbar Schreibzugriffe erlauben.

Im Klartext: Existieren Daten sowohl im VirtualStore als auch in den eigentlichen originalen Positionen, dann werden immer die Daten des VirtualStore verwendet. Nur wenn der entsprechende Registry Key nicht vorhanden/gelöscht wird oder die entsprechende Datei nicht vorhanden/gelöscht ist, dann werden die Daten aus den original Verzeichnissen bzw. Registryästen verwendet.

Nur daraus folgt ein Problem:
Macht der Admin Korrekturen an den realen Daten UND es existieren Daten im VirtualStore, dann bleiben die Änderungen des Admins wirkungslos, bis er die Daten aus dem VirtualStore entfernt. Das kann eine spannende Aufgabe werden.
Vielleicht ist dies eine profane Erkenntnis, aber die Implikationen sind meines Erachtens immens.

PS: Gemein ist einfach, dass Software die bisher mit einer Fehlermeldung gerechnet hat, wenn ein Schreibversuch nach HKLM oder C:\Program Files erfolgte, nun auf einmal erfolgreich schreiben kann. Da kann man sich noch so sehr an alle Empfehlungen halten, hier wird man von Vista reingelegt und man muss schleunigst das entsprechende Trustinfo Manifest nachrüsten.

„Datenschutz Overkill“ einmal anders…

Das Büro in dem ich arbeite liegt in einem wunderschönen renovierten ehemaligen Kasernengebäude vom Anfang des letzten Jahrhunderts. Mit unserer Firma sind hier noch 5 andere Firmen und eine Gaststätte im Haus.

In der Nacht von Dienstag auf Mittwoch hat man bei 3 der Firmen eingebrochen, alles was nicht niet- und nagelfest war wurde mitgenommen. Insbesondere Computer, Flachbildschirme und Kopierer. Das Büro gegenüber, das über uns und das unter uns hat es erwischt. Einige schon zum dritten Mal, obwohl wir hier direkt an einer belebten Hauptstraße liegen mit der Polizei in Sichtweite.
Aber wen kümmert schon ein Kleinlaster mitten in der Nacht in den irgendwelche Leute irgendwas einladen.

Es war wieder einmal ernüchternd zu sehen wie notwendig Datenschutz wirklich ist. Die meisten Firmen haben auch Ihre aktuellen Daten mit samt Sicherung verloren, weil diese auch in den Räumen mit aufbewahrt wurde.

Datenschutz fängt wirklich bei der äußeren Hülle an (Tür+Alarmanlage) und geht strickt weiter über zentrale Datenhaltung (Raid5 System) und natürlich bis hin zu regelmäßigen Backups und externen Festplatten, die auch wirklich und garantiert nicht in den eigenen Räumen aufbewahrt werden!
Ja wissen tut es jeder, aber wer handelt auch wirklich danach?

Wer diese Büros und die frustrierten Mitarbeiter gesehen hat, die Ihre Arbeit von Wochen und Monaten verloren haben, der ist kuriert…

Es gibt eben auch notwendigen „Datenschutz“ 😉

Datenschutz Overkill

Also irgendwo ist es nicht mehr zu begreifen. Datenschutz ist Okay, aber was nun mit dem neuen Datenschutzgesetz verabschiedet wurde ist die Dämlichkeit hoch drei.

Und das hier einer neuen Abmahnungswelle Tür und Tor geöffnet wird ist einfach nicht mehr zu begreifen.

Verstöße gehören nicht abgemahnt, sondern zentral gemeldet.

Nun wird sich keiner wundern, wenn er nun auf meinem Blog diese Datenschutzhinweise findet und auch den Anmelde Dialog in neuem Gewand vorfindet!

Mehr dazu auch hier:

Button + Accelerator + ShowWindow(SW_HIDE) – EnableWindow(FALSE) = Falle

Da hat man einen Multifunktionalen Dialog. Einer der Schalter in dem Dialog heißt Delete. Und das D ist als Accelerator mit einem & versehen. Gemäß einer internen Rechteverwaltung haben manche Nutzer nicht das Recht diesen Button zu benutzen. Der Programmierer (nicht ich ;-)) hat in diesem Fall einfach den Schalter mit ShowWindow(SW_HIDE) verborgen. Ein weiterer Test ob die Rechte wirklich gegeben sind entfiel im OnBtDelete Handler.

Nun stellte sich aber heraus, dass es manche Nutzer geschafft haben, dennoch Einträge zu löschen.

Nun der Grund ist einfach. Solange der Button nicht mit EnableWindow(FALSE) auch disabled wird, kann man mit ALT+D, also Drücken der ALT-Taste und des Accelerators diesen Schalter auslösen.

Jo. So einfach hat man ein Userinterface gebastelt, mit dem man sich hereinlegen kann.