Leer en inglés

Compartir vía


Acceso con privilegios elevados para comandos de dotnet

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 global

Los recursos de paquete deben instalarse en una ubicación protegida con la opción --tool-path. Con esta separación se pretende aislar un entorno de usuario con privilegios restringidos de un entorno con privilegios elevados.

Bash
sudo dotnet tool install PACKAGEID --tool-path /usr/local/share/dotnet-tools

Se creará /usr/local/share/dotnet-tools con permiso drwxr-xr-x. Si ya existe el directorio, use el comando ls -l para comprobar que los usuarios restringidos no tienen permiso para editar el directorio. Si es así, use el comando sudo chmod o-w -R /usr/share/dotnet-tools para quitar el acceso.

Ejecución de la herramienta global

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

Bash
sudo /usr/local/share/dotnet-tools/TOOLCOMMAND

Opción 2 Agregue el vínculo del símbolo de la herramienta, una vez por cada herramienta:

Bash
sudo ln -s /usr/local/share/dotnet-tools/TOOLCOMMAND /usr/local/bin/TOOLCOMMAND

Y ejecute con:

Bash
sudo TOOLCOMMAND

Desinstalación de la herramienta global

Bash
sudo dotnet tool uninstall PACKAGEID --tool-path /usr/local/share/dotnet-tools

Si ha realizado un vínculo de símbolo, también deberá quitarlo:

Bash
sudo rm /usr/local/bin/TOOLCOMMAND

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):

    CLI de .NET
    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:

    CLI de .NET
    dotnet build
    sudo dotnet run --no-build
    

Vea también