Compartir a través de

Acceso con privilegios elevados para comandos de .NET

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

Los comandos siguientes se pueden ejecutar con privilegios elevados:

No se recomienda ejecutar otros comandos con privilegios elevados. En concreto, no se recomienda la elevación con comandos que usan MSBuild, como dotnet restore, dotnet build y dotnet run. El problema principal son los problemas de administración de permisos cuando un usuario pasa entre el usuario raíz y una cuenta restringida después de emitir comandos 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 realice la transición entre 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 herramientas globales

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

Instalación de la herramienta

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

  • Haga clic con el botón derecho en la %ProgramFiles%\dotnet-tools carpeta y seleccione Propiedades. Se abre el cuadro de diálogo Propiedades comunes .
  • Seleccione la pestaña Seguridad . En Nombres de grupo o de usuario, compruebe si el grupo "Usuarios" tiene permiso para escribir o modificar el directorio.
  • Si el grupo "Usuarios" no puede escribir o modificar el directorio, use un nombre de directorio diferente al instalar las herramientas en lugar 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".

Ejecuta 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 tiene que 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 por árbol de subdirectorios, por usuario. Cuando se ejecutan con privilegios elevados, las herramientas locales comparten un entorno de usuario restringido al entorno con privilegios elevados. En Linux y macOS, esto da como resultado que los archivos se establezcan con acceso de solo usuario raíz. Si el usuario vuelve a una cuenta restringida, el usuario ya no puede acceder ni escribir en los archivos. 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 directrices anteriores para las herramientas globales.

Aumento de nivel durante el desarrollo

Durante el desarrollo, es posible que necesite acceso elevado 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 algunos patrones, como se indica a continuación:

  • Uso del 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

Consulte también