__COMPAT_LAYER=RunAsInvoker verhindert Start von osk.exe

[Christoph Schneegans]

Hallo allerseits!

Ich setze seit einiger Zeit die Umgebungsvariable

__COMPAT_LAYER=RunAsInvoker

in meinen Windows-10-Installationen, damit Prozesse wie regedit.exe oder
SystemPropertiesAdvanced.exe nicht automatisch angehoben werden, sondern
mit Benutzerrechten laufen. (Wenn ich solche Prozesse stattdessen mit
Administratorrechten starten will, tue ich das aus einer bereits
angehobenen PowerShell-Sitzung heraus.)

Nun habe ich unerwarteterweise ein Programm gefunden, das damit nicht
funktioniert, nämlich C:\windows\system32\osk.exe. Der Aufruf

set __COMPAT_LAYER=RunAsInvoker & c:\windows\system32\osk.exe

aus cmd.exe heraus führt hier reproduzierbar zum Absturz, während

set __COMPAT_LAYER= & c:\windows\system32\osk.exe

anstandslos läuft.

Argh! Was soll denn sowas?

[Michael Graf]

Hi!

Post by Christoph Schneegans
Hallo allerseits!
Ich setze seit einiger Zeit die Umgebungsvariable
__COMPAT_LAYER=RunAsInvoker
in meinen Windows-10-Installationen, damit Prozesse wie regedit.exe oder
SystemPropertiesAdvanced.exe nicht automatisch angehoben werden, sondern
mit Benutzerrechten laufen. (Wenn ich solche Prozesse stattdessen mit
Administratorrechten starten will, tue ich das aus einer bereits
angehobenen PowerShell-Sitzung heraus.)
Nun habe ich unerwarteterweise ein Programm gefunden, das damit nicht
funktioniert, nämlich C:\windows\system32\osk.exe. Der Aufruf
set __COMPAT_LAYER=RunAsInvoker & c:\windows\system32\osk.exe
aus cmd.exe heraus führt hier reproduzierbar zum Absturz, während
set __COMPAT_LAYER= & c:\windows\system32\osk.exe
anstandslos läuft.
Argh! Was soll denn sowas?

Keine Ahnung. Ins Blaue:
Ist in der Registry was in
HKEY_CLASSES_ROOT\*\shell\forcerunasinvoker
gesetzt zur Bildschirmtastatur?

Michael

[Michael Graf]

Hi!

Post by Michael Graf
Ist in der Registry was in
HKEY_CLASSES_ROOT\*\shell\forcerunasinvoker
gesetzt zur Bildschirmtastatur?

Das sollte standardmäßig nicht so sein, aber wie gesagt, "ins Blaue".

Michael

[Christoph Schneegans]

Post by Michael Graf

Post by Christoph Schneegans
Der Aufruf
set __COMPAT_LAYER=RunAsInvoker & c:\windows\system32\osk.exe
aus cmd.exe heraus führt hier reproduzierbar zum Absturz, während
set __COMPAT_LAYER= & c:\windows\system32\osk.exe
anstandslos läuft.
Argh! Was soll denn sowas?

Ist in der Registry was in
HKEY_CLASSES_ROOT\*\shell\forcerunasinvoker
gesetzt zur Bildschirmtastatur?

Die etwa in
<http://www.dxsdata.com/de/2015/12/windows-run-application-explicitly-without-admin-permissions-default-user/>
beschriebenen Registry-Schlüssel erzeugen ja lediglich einen
Kontextmenü-Eintrag, der vor dem Start eines Programms die fragliche
Umgebungsvariable setzt. (Einen äquivalenten Effekt erzielt man übrigens mit
<https://dandini.wordpress.com/tag/__compat_layerrunasinvoker/>.)

[Stefan Kanthak]

Post by Christoph Schneegans
Hallo allerseits!
Ich setze seit einiger Zeit die Umgebungsvariable
__COMPAT_LAYER=RunAsInvoker
in meinen Windows-10-Installationen, damit Prozesse wie regedit.exe oder
SystemPropertiesAdvanced.exe nicht automatisch angehoben werden, sondern
mit Benutzerrechten laufen. (Wenn ich solche Prozesse stattdessen mit
Administratorrechten starten will, tue ich das aus einer bereits
angehobenen PowerShell-Sitzung heraus.)
Nun habe ich unerwarteterweise ein Programm gefunden, das damit nicht
funktioniert, nämlich C:\windows\system32\osk.exe. Der Aufruf
set __COMPAT_LAYER=RunAsInvoker & c:\windows\system32\osk.exe
aus cmd.exe heraus führt hier reproduzierbar zum Absturz, während
set __COMPAT_LAYER= & c:\windows\system32\osk.exe
anstandslos läuft.
Argh! Was soll denn sowas?

Du bewunderst gerade die Verbrechen eines unfaehigen Entwicklers, der
die Vorgaben seiner eigenen Firma missachtet hat, Returncodes bei allen
Aufrufen von (System-)Schnittstellen, wodurch osk.exe beim Start ohne
Administratorrechte auf einen zum Absturz fuehrenden Fehler laeuft.

Stefan
[

[Christoph Schneegans]

Post by Stefan Kanthak

Post by Christoph Schneegans
Der Aufruf
set __COMPAT_LAYER=RunAsInvoker & c:\windows\system32\osk.exe
aus cmd.exe heraus führt hier reproduzierbar zum Absturz, während
set __COMPAT_LAYER= & c:\windows\system32\osk.exe
anstandslos läuft.

Du bewunderst gerade die Verbrechen eines unfaehigen Entwicklers, der
die Vorgaben seiner eigenen Firma missachtet hat, Returncodes bei allen
Aufrufen von (System-)Schnittstellen, wodurch osk.exe beim Start ohne
Administratorrechte auf einen zum Absturz fuehrenden Fehler laeuft.

Ja, aber osk.exe stürzt wirklich genau dann ab, wenn
__COMPAT_LAYER=RunAsInvoker gesetzt ist, und zwar sowohl in
eingeschränkten als auch Administrator-Konten. Dieses Verhalten habe ich
noch bei keinem anderen Programm gesehen.

Ansonsten funktioniert __COMPAT_LAYER=RunAsInvoker in Windows 10 nämlich
wirklich gut, und ich wollte nicht mehr ohne arbeiten. Allein die
Tatsache, daß man andernfalls etwa SystemPropertiesAdvanced.exe nur
angehoben starten kann...

[Takvorian]

Post by Christoph Schneegans
Ansonsten funktioniert __COMPAT_LAYER=RunAsInvoker in Windows 10 nämlich
wirklich gut, und ich wollte nicht mehr ohne arbeiten. Allein die
Tatsache, daß man andernfalls etwa SystemPropertiesAdvanced.exe nur
angehoben starten kann...

Man könnte sich eher fragen, warum man sie unbedingt abgesenkt starten will.
Der in Manifesten vorgesehene Level "HighestAvailable" ist ja so sinnlos
nicht. Gewisse Operationen brauchen nun mal erhöhte Rechte, gerade auch bei
besagtem Programm. Man kann's mit dem Sicherheitswahn auch übertreiben. Die
Sache wirkt schon fast so sektiererisch wie die der zwanghaften
AV-Ware-Sekte. Hier gibt's genau nichts, was zwangsweise auf RunAsinvoker
gesetzt ist.

[Christoph Schneegans]

Post by Takvorian

Post by Christoph Schneegans
Ansonsten funktioniert __COMPAT_LAYER=RunAsInvoker in Windows 10 nämlich
wirklich gut, und ich wollte nicht mehr ohne arbeiten. Allein die
Tatsache, daß man andernfalls etwa SystemPropertiesAdvanced.exe nur
angehoben starten kann...

Man könnte sich eher fragen, warum man sie unbedingt abgesenkt starten will.
Der in Manifesten vorgesehene Level "HighestAvailable" ist ja so sinnlos
nicht. Gewisse Operationen brauchen nun mal erhöhte Rechte, gerade auch bei
besagtem Programm.

Mit SystemPropertiesAdvanced.exe stellt man u.a. die Umgebungsvariablen
ein. Zum Einstellen von Benutzervariablen braucht man keine erhöhten
Rechte. Es ist offensichtlich eine Verletzung des "Principle of least
privilege", wenn man das Programm, mit dem man Benutzervariablen
einstellt, nur angehoben starten kann.

Und für eingeschränkte Konten geht es überhaupt nicht anders: Ohne
__COMPAT_LAYER=RunAsInvoker will SystemPropertiesAdvanced.exe
Administratorrechte haben – dann jedoch kann man nur die
Benutzervariablen des Administrators ändern, aber nicht die eigenen.

[Takvorian]

Post by Christoph Schneegans
Mit SystemPropertiesAdvanced.exe stellt man u.a. die Umgebungsvariablen
ein. Zum Einstellen von Benutzervariablen braucht man keine erhöhten
Rechte. Es ist offensichtlich eine Verletzung des "Principle of least
privilege", wenn man das Programm, mit dem man Benutzervariablen
einstellt, nur angehoben starten kann.
Und für eingeschränkte Konten geht es überhaupt nicht anders: Ohne
__COMPAT_LAYER=RunAsInvoker will SystemPropertiesAdvanced.exe
Administratorrechte haben – dann jedoch kann man nur die
Benutzervariablen des Administrators ändern, aber nicht die eigenen.

Zum Ändern der Benutzervariablen braucht man SystemPropertiesAdvanced.exe
nicht. Das kann man in Systemsteuerung/Benutzerkonten machen.
Der Link "Eigene Umgebungsvariablen ändern", der lange Zeit nicht benutzbar
war, ist nun wieder benutzbar. Oder Regedit: im Userkonto wird es eh immer
eingeschränkt gestartet, im Adminkonto hingegen erhöht. Gut, man könnte es
auch da eingeschränkt starten, wenn man nur passende Dinge bearbeiten will.
Ich starte es lieber gleich erhöht. Zusätzlich noch ein Link, der es mit
System- plus TrustedInstaller-Rechten startet, um ggf. alle Schlüssel ohne
Bastelei an den Rechten bearbeiten zu können. Oder man startet es, wie
Stefan öfter schreibt, mit Backup-Privilegien...