La détection de registre de virtualisation

J'ai un ensemble de C# (v2) apps et j'ai du mal avec le registre de la virtualisation dans Win7 (et dans une moindre mesure Vista).

Je partage un registre de configuration de la zone que mes applications ont besoin d'y accéder dans des HKLM\Software\Société... Avant de Vista, tout était écrit et de la lecture à partir de cet emplacement tant que de besoin.

Le code correctement détecté échecs à écrire à cette clé de registre et de se replier de façon appropriée (écrit à HKCU au lieu et en informant l'utilisateur que les paramètres qu'ils avaient appliqué affecte uniquement l'utilisateur actuel).

Dans Vista, registre de virtualisation cassé tout cela parce que le contrôle d'accès, nous avons été à l'aide de la clé HKLM d'écrire "réussir" dans le silence et la virtualisation de HKCR\VirtualStore\Machine... à la place. Dans ce cas, l'utilisateur pourrait croire qu'ils avaient sauvé l'échelle de l'ordinateur de configuration, mais cela avait seulement écrit dans le magasin virtuel.

Malheureusement, même en essayant d'énumérer les autorisations sur la clé de registre HKLM explicitement renvoie des résultats indiquant que l'utilisateur a accès qu'on le soit ou pas.

Lorsque nous avons ajouté le support de Vista, la solution que nous avons utilisée était d'effectuer une sonde écrire HKLM... et puis vérifier dans HKCR\VirtualStore\Machine... pour la même valeur et notez que la virtualisation a eu lieu si la valeur a été trouvé.

Win7 semble avoir cassé ce (nouveau), car les requêtes contre l'explicite emplacement virtuel (HKCR) montrons maintenant fusionné les résultats de l'emplacement HKLM même si l'écriture n'a pas été virtualisé.

Quelqu'un aurait-il des suggestions pour travailler autour de cela?

Contraintes:
- J'ai besoin d'une solution qui fonctionne sans nécessiter d'élévation (quand je n'ai pas des autorisations de niveau administrateur je vais secours à par-configuration de l'utilisateur dans HKCU mais j'ai besoin d'être en mesure de détecter ce cas de manière fiable).

Il doit travailler avec une v2 application en C# (Une option que j'ai vu, le code C++ est d'intégrer un manifeste qui désactive la virtualisation pour les .exe, mais je n'ai pas été en mesure de le faire en C# V2 voir désactiver dossier de virtualisation de windows).
Il a besoin de travailler sans un "programme d'installation" (ce qui exclut la possibilité de désactiver la virtualisation sur la clé de registre que nous avons besoin d'ala le REG DRAPEAUX... commande).

Avez-vous essayé d'utiliser boxedapp? Il peut aider. Bonne chance!
Vous devez utiliser boxedapppacker ou boxedapp. Itemulate de registre du système pour une application.

InformationsquelleAutor |

11

C'est une excellente question posée, +1 (Pourquoi est-il de la communauté wiki, il mérite des points!)

En général, il existe un ensemble de règles (qui [comme vous avez] variera au fil du temps) qui contrôle si le contrôle de compte d'utilisateur [et donc, implicitement, de Registre] la virtualisation sont en jeu.

Quelques éléments saillants de la Registre de Virtualisation de règles documentation MSDN sont:
1. [comme jeffamaphone dit] si le manifeste est un requestedPrivileges/requestedExecutionLevel ensemble, c'est désactivée. Vous ne semblez pas avoir écarté l'ajout d'un manifeste, de sorte que pouvez-vous indiquer pourquoi cela ne fonctionne pas pour vous? (Vous dites "je n'ai pas été en mesure de le faire en C# V2" - il y a un Ajout d'Élément option pour ajouter un fichier de manifeste d'application, et qui est disponible en VS2005)
2. si le fichier exe est en cours d'exécution 64 bits, son off par défaut
3. si ce n'est pas un processus interactif (comme un service, ou hébergé dans IIS, etc.), il est hors
Si vous n'êtes pas en mesure d'influencer l'un des ci-dessus, qui est l'idéal, et ainsi vous voulez détecter si le contrôle de compte d'utilisateur virtualisation s'applique dans le contexte actuel, l'utilisation cette réponse à ce qui pourrait à première vue ne pas appeat être une question. (Évidemment, vous auriez encore besoin de décider si elle s'applique à la clé spécifique que vous êtes d'exploitation, qui est une cible mouvante qui de toute évidence vous ne voulez à mettre en œuvre le code qui a besoin de suivre les changements si elle peut être évitée, mais dans la plupart des cas, il devrait être assez clair.)

InformationsquelleAutor
2

Vous pouvez activer /désactiver la virtualisation sur une clé de base, selon cette, mais il vous dit d'utiliser un outil de ligne de commande. Mais il doit y avoir un moyen de le faire par programmation.

Il pourrait être plus facile de simplement désactiver la virtualisation dans votre application entièrement en définissant requestedExecutionLevel dans votre manifeste. Vous pouvez essayer de highestAvailable, mais qui pourrait signifier que votre application s'exécute en tant qu'Administrateur. Il semble impliquer un peu mise à asInvoker va désactiver la virtualisation. Voir aussi.
- Malheureusement je ne peux pas désactiver la virtualisation sur la clé, parce que je dois être élevé pour faire cela. Je ne peux pas utiliser le manifeste approche, parce que c'est seulement respectée pour l'entrée .exe, et pas quand je suis hébergé dans une autre application. (il n'est également pas pris en charge par le 2.0 compilateur C#)
- L'utilisation de REG désactiver la virtualisation sur mon domaine dans HKLM est un bijou. J'ai besoin de conserver les données à travers les connexions de l'utilisateur et de préserver la compatibilité avec les anciennes versions de systèmes d'exploitation (XP... et oui je sais que c'est mort, mais il n'est pas!).
InformationsquelleAutor i_am_jorf
1

Noter que HKCR est virtualisé magasin lui-même, une combinaison de HKLM\Software\Classes et HKCU\Software\Classes.

La meilleure approche serait de même pas laisser le registre de virtualisation de prendre place. Tout d'abord vérifier que l'utilisateur est élevée au moment de l'exécution puis vous pouvez informer l'utilisateur que les changements ne sera pas appliqué à l'utilisateur en cours avant même de commencer à faire des changements.

En détectant si vous êtes un administrateur élevé dans la première place, vous pouvez simplement éviter d'écrire sur la clé HKLM quand ça va être virtualisés.

Exemple:
```
private bool IsAdministrator
{
    get
    {
        WindowsIdentity wi = WindowsIdentity.GetCurrent();
        WindowsPrincipal wp = new WindowsPrincipal(wi);

        return wp.IsInRole(WindowsBuiltInRole.Administrator);
    }
}
```
Remarque: je n'ai pas de code en C#, l'exemple est levée à partir de la question Comment puis-je détecter si mon exécution du processus de contrôle de compte d'utilisateur-élevé ou pas?

InformationsquelleAutor
1

J'ai eu un problème similaire et l'introduction d'un manifeste résolu.

Je comptais sur le registre de sécurité pour empêcher l' (Win32) d'application à partir de la création de clés dans la HKLM/Software/Wow6432Node lors de l'exécution comme d'utilisateur standard, et a été très surpris de voir que c'était succeceding peu importe, mais pas de clé était présent et il a été créé en vertu de cette nouvelle VirtualStore zone.

Le registre de la virtualisation est éteint lorsque le PE manifeste est révélé contenir des informations relatives à la sécurité. Pour ne pas nécessiter une élévation des privilèges de mon manifeste contient le nœud suivant:
```
<trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
   <security>
      <requestedPrivileges>
         <requestedExecutionLevel level="asInvoker">
         </requestedExecutionLevel>
      </requestedPrivileges>
   </security>
</trustInfo>
```
Pour le fichier exécutable pour être compatible avec Vista et XP, apparemment, chaque nœud dans le TrustInfo section doit contenir les noms:
```
<ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
   <ms_asmv2:security>
      <ms_asmv2:requestedPrivileges>
         <ms_asmv2:requestedExecutionLevel level="asInvoker">
         </ms_asmv2:requestedExecutionLevel>
      </ms_asmv2:requestedPrivileges>
   </ms_asmv2:security>
</ms_asmv2:trustInfo>
```
Une fois que le manifeste a été correctement intégré dans mon .exe (il m'a fallu plusieurs essais en modifiant les propriétés appropriées du projet), le programme a été au dernier défaut que j'attendais.

Pour le code managé, le manifeste peut être compris comme une étape de post-construction par l'exécution de l'mt.exe outil de. Par exemple, comme indiqué dans le Article MSDN
```
mt.exe –manifest YourFile.manifest –outputresource:YourApp.exe;#1
```
Je préfère utiliser le manifeste approche plutôt que de modifier les drapeaux de la base de registre à l'aide de nœuds reg.exe comme expliqué dans cet article que cela rend le comportement cohérent sur toutes les machines.

Espère que ça aide (même si, après avoir lu la date du post d'origine, je suis sûr que le problème a été résolu il y a longtemps!!)

Alberto

InformationsquelleAutor

Vous devez vous connecter pour publier un commentaire.