Compartir a través de

Acceso con privilegios elevados para comandos de dotnet

  • Artículo

Los procedimientos recomendados de desarrollo de software sirven de guía a los desarrolladores para escribir software que requiera la menor cantidad de privilegios. Sin embargo, algunos programas, como las herramientas de supervisión de rendimiento, requieren permiso del administrador debido a las reglas del sistema operativo. En las siguientes instrucciones se describen los escenarios admitidos para escribir dicho software con .NET Core.

Los siguientes comandos se pueden ejecutar con privilegios elevados:

No se recomienda ejecutar otros comandos con privilegios elevados. En concreto, no se recomienda usar privilegios elevados con los comandos que usa MSBuild, como dotnet restore, dotnet build y dotnet run. Los problemas de administración de permisos son el principal problema cuando un usuario cambia varias veces entre una cuenta restringida y otra raíz después de emitir comandos de dotnet. Como usuario restringido, es posible que no tenga acceso al archivo generado por un usuario raíz. Hay maneras de resolver esta situación, pero, para empezar, no es necesario que surjan.

Puede ejecutar comandos como raíz siempre y cuando no cambie repetidas veces entre la raíz y una cuenta restringida. Por ejemplo, los contenedores de Docker se ejecutan como raíz de forma predeterminada, por lo que tienen esta característica.

Instalación de herramienta global

En las instrucciones siguientes se muestra la manera recomendada de instalar, ejecutar y desinstalar las herramientas de .NET que necesitan privilegios elevados para ejecutarse.

Instalación de la herramienta

Si la carpeta %ProgramFiles%\dotnet-tools ya existe, siga este procedimiento para comprobar si el grupo "Usuarios" tiene permiso para escribir o modificar ese directorio:

  • Haga clic con el botón derecho en la carpeta %ProgramFiles%\dotnet-tools y seleccione Propiedades. Se abrirá el cuadro de diálogo Propiedades comunes.
  • Seleccione la pestaña Seguridad. En Nombres de grupos o usuarios, compruebe si el grupo "Usuarios" tiene permiso para escribir o modificar el directorio.
  • Si el grupo "Usuarios" no puede escribir o modificar el directorio, al instalar las herramientas, use otro nombre de directorio de dotnet-tools.

Para instalar las herramientas, ejecute el siguiente comando en un símbolo del sistema con privilegios elevados. Creará la carpeta dotnet-tools durante la instalación.

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

Ejecución de la herramienta global

Opción 1 Use la ruta de acceso completa con privilegios elevados:

"%ProgramFiles%\dotnet-tools\TOOLCOMMAND"

Opción 2 Agregue la carpeta recién creada a %Path%. Solo necesita realizar esta operación una vez.

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

Y ejecute con:

TOOLCOMMAND

Desinstalación de la herramienta global

En un símbolo del sistema con privilegios elevados, escriba el siguiente comando:

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

Herramientas locales

Las herramientas locales se limitan al árbol de subdirectorio, por usuario. Cuando se ejecutan con privilegios elevados, las herramientas locales comparten un entorno de usuario con privilegios restringidos en el entorno con privilegios elevados. En Linux y macOS, esto da como resultado archivos que establecen con acceso de solo usuario raíz. Si el usuario cambia a una cuenta restringida, el usuario ya no podrá acceder a los archivos ni escribir en ellos. Por tanto, no se recomienda instalar las herramientas que necesiten permisos elevados como herramientas locales. En su lugar, use la opción --tool-path y las instrucciones anteriores para las herramientas globales.

Elevación durante el desarrollo

Durante el desarrollo, puede que necesite acceso con privilegios elevados para probar la aplicación. Este escenario es común para las aplicaciones de IoT, por ejemplo. Se recomienda que compile la aplicación sin la elevación y, a continuación, la ejecute con privilegios elevados. Hay unos pocos patrones, como los siguientes:

  • Uso de archivo ejecutable generado (proporciona el mejor rendimiento de inicio):

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

  • Mediante el comando dotnet run con la marca —no-build para evitar que se generen nuevos archivos binarios:

    dotnet build
sudo dotnet run --no-build

Vea también