Partager via

Accès élevé pour les commandes dotnet

Les meilleures pratiques en matière de développement de logiciels guident les développeurs pour écrire des logiciels nécessitant le moins de privilèges. Toutefois, certains logiciels, comme les outils de surveillance des performances, nécessitent une autorisation d’administrateur en raison de règles de système d’exploitation. Les instructions suivantes décrivent les scénarios pris en charge pour l’écriture de tels logiciels avec .NET Core.

Les commandes suivantes peuvent être exécutées avec élévation de privilèges :

  • dotnet tool commandes, telles que dotnet tool install.
  • dotnet run --no-build
  • dotnet-core-uninstall

Nous vous déconseillons d’exécuter d’autres commandes avec élévation de privilèges. En particulier, nous vous déconseillons d’élévation avec des commandes qui utilisent MSBuild, telles que dotnet restore, dotnet build et dotnet run. Le problème principal est les problèmes de gestion des autorisations lorsqu’un utilisateur effectue une transition entre la racine et un compte restreint après avoir émis des commandes dotnet. Vous pouvez trouver en tant qu’utilisateur restreint que vous n’avez pas accès au fichier généré par un utilisateur racine. Il existe des moyens de résoudre cette situation, mais ils ne sont pas nécessaires pour entrer dans la première place.

Vous pouvez exécuter des commandes en tant que racine tant que vous ne effectuez pas de transition entre la racine et un compte restreint. Par exemple, les conteneurs Docker s’exécutent en tant que racine par défaut, de sorte qu’ils ont cette caractéristique.

Installation globale de l’outil

Les instructions suivantes illustrent la méthode recommandée pour installer, exécuter et désinstaller des outils .NET qui nécessitent des autorisations élevées pour s’exécuter.

Installer l’outil

Si le dossier %ProgramFiles%\dotnet-tools existe déjà, procédez comme suit pour vérifier si le groupe « Utilisateurs » dispose de l’autorisation d’écrire ou de modifier ce répertoire :

  • Cliquez avec le bouton droit sur le %ProgramFiles%\dotnet-tools dossier et sélectionnez Propriétés. La boîte de dialogue Propriétés communes s’ouvre.
  • Sélectionnez l’onglet Sécurité . Sous Noms de groupe ou d’utilisateur, vérifiez si le groupe « Utilisateurs » a l’autorisation d’écrire ou de modifier le répertoire.
  • Si le groupe « Utilisateurs » ne peut pas écrire ou modifier le répertoire, utilisez un nom de répertoire différent lors de l’installation des outils plutôt que des outils dotnet-tools.

Pour installer des outils, exécutez la commande suivante dans l’invite avec élévation de privilèges. Il crée le dossier dotnet-tools pendant l’installation.

dotnet tool install PACKAGEID --tool-path "%ProgramFiles%\dotnet-tools".

Exécuter l’outil global

Option 1 Utilisez le chemin d’accès complet avec une invite avec élévation de privilèges :

"%ProgramFiles%\dotnet-tools\TOOLCOMMAND"

Option 2 Ajoutez le dossier nouvellement créé à %Path%. Vous n’avez besoin d’effectuer cette opération qu’une seule fois.

setx Path "%Path%;%ProgramFiles%\dotnet-tools\"

Et exécutez avec :

TOOLCOMMAND

Désinstaller l’outil global

Dans une invite avec élévation de privilèges, tapez la commande suivante :

dotnet tool uninstall PACKAGEID --tool-path "%ProgramFiles%\dotnet-tools"

Outils locaux

Les outils locaux sont délimités par arborescence de sous-répertoires, par utilisateur. Lors de l’exécution avec élévation de privilèges, les outils locaux partagent un environnement utilisateur restreint à l’environnement avec élévation de privilèges. Dans Linux et macOS, cela entraîne la définition de fichiers avec un accès utilisateur racine uniquement. Si l’utilisateur revient à un compte restreint, l’utilisateur ne peut plus accéder aux fichiers ni y écrire. Par conséquent, l’installation d’outils qui nécessitent une élévation en tant qu’outils locaux n’est pas recommandé. Utilisez plutôt l’option --tool-path et les instructions précédentes pour les outils globaux.

Élévation pendant le développement

Pendant le développement, vous devrez peut-être disposer d’un accès élevé pour tester votre application. Ce scénario est courant pour les applications IoT, par exemple. Nous vous recommandons de générer l’application sans élévation, puis de l’exécuter avec élévation. Voici quelques modèles :

  • Utilisation de l’exécutable généré (il fournit les meilleures performances de démarrage) :

    dotnet build
sudo ./bin/Debug/netcoreapp3.0/APPLICATIONNAME

  • Utilisation de la commande dotnet run avec l’indicateur —no-build pour éviter de générer de nouveaux fichiers binaires :

    dotnet build
sudo dotnet run --no-build

Voir aussi