Acesso elevado para os comandos dotnet

As melhores práticas de desenvolvimento de software orientam os desenvolvedores a escrever um software que exija o mínimo de privilégios. No entanto, alguns softwares, como as ferramentas de monitoramento de desempenho, requerem permissão de administrador devido a regras do sistema operacional. As diretrizes a seguir descrevem os cenários compatíveis com a gravação desse software com o .NET Core.

Os seguintes comandos podem ser executados com privilégios elevados:

• comandos dotnet tool, como instalação de ferramenta dotnet.
• dotnet run --no-build
• dotnet-core-uninstall

Não recomendamos executar outros comandos com privilégios elevados. Particularmente, não recomendamos privilégios elevados com comandos que usam o MSBuild, como dotnet restore, dotnet build e dotnet run. O principal problema é o gerenciamento de permissões quando um usuário faz a transição entre a raiz e uma conta restrita várias vezes após a emissão de comandos dotnet. Você pode achar, como um usuário restrito, que não tem acesso ao arquivo criado por um usuário raiz. Existem maneiras de resolver esta situação, mas não é necessário entrar nesse assunto agora.

É possível executar comandos como raiz, desde que não faça a transição entre a raiz e uma conta restrita. Por exemplo, os contêineres do Docker são executados como raiz por padrão, então eles têm essa característica.

Instalação da ferramenta global

As instruções a seguir demonstram a maneira recomendada de instalar, executar e desinstalar ferramentas do .NET que exigem permissões elevadas para serem executadas.

Windows

Instalar a ferramenta

Se a pasta %ProgramFiles%\dotnet-tools já existir, faça o seguinte para verificar se o grupo “Usuários” tem permissão para gravar ou modificar esse diretório:

• Clique com o botão direito do mouse na pasta %ProgramFiles%\dotnet-tools e selecione Propriedades. A caixa de diálogo Propriedades Comuns é aberta.
• Selecione a guia Segurança. Em Nomes de grupo ou de usuário, verifique se o grupo "Usuários" tem permissão para gravar ou modificar o diretório.
• Se o grupo “Usuários” não puder gravar ou modificar o diretório, use um nome de diretório diferente ao instalar as ferramentas em vez de dotnet-tools.

Para instalar as ferramentas, execute o seguinte comando no prompt com privilégios elevados. Ele criará a pasta dotnet-tools durante a instalação.

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

Executar a ferramenta global

Opção 1 Usar o caminho completo com prompt com privilégios elevados:

"%ProgramFiles%\dotnet-tools\TOOLCOMMAND"

Opção 2 Adicionar a pasta recém-criada ao %Path%. Você só precisa fazer essa operação uma vez.

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

E execute com:

TOOLCOMMAND

Desinstalar a ferramenta global

No prompt de privilégios elevados, digite o seguinte comando:

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

Linux

Instalar a ferramenta global

Os ativos de pacote devem ser instalados em um local protegido usando a opção --tool-path. Essa separação evita o compartilhamento de um ambiente de usuário restrito com um ambiente com privilégios elevados.

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

/usr/local/share/dotnet-tools será criado com a permissão drwxr-xr-x. Se o diretório já existir, use o comando ls -l para verificar se o usuário restrito não tem permissão para editar o diretório. Nesse caso, use o comando sudo chmod o-w -R /usr/share/dotnet-tools para remover o acesso.

Executar a ferramenta global

Opção 1 Usar o caminho completo com o sudo:

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

Opção 2 Adicionar o link do símbolo da ferramenta, uma vez por ferramenta:

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

E execute com:

sudo TOOLCOMMAND

Desinstalar a ferramenta global

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

Se tiver feito um link de símbolo, você também precisará removê-lo:

sudo rm /usr/local/bin/TOOLCOMMAND

macOS

Instalar a ferramenta global

Os ativos de pacote devem ser instalados em um local protegido usando a opção --tool-path. Essa separação evita o compartilhamento de um ambiente de usuário restrito com um ambiente com privilégios elevados.

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

/usr/local/share/dotnet-tools será criado com a permissão drwxr-xr-x. Se o diretório já existir, use o comando ls -l para verificar se o usuário restrito não tem permissão para editar o diretório. Nesse caso, use o comando sudo chmod o-w -R /usr/share/dotnet-tools para remover o acesso.

Executar a ferramenta global

Opção 1 Usar o caminho completo com o sudo:

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

Opção 2 Adicionar o link do símbolo da ferramenta, uma vez por ferramenta:

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

E execute com:

sudo TOOLCOMMAND

Desinstalar a ferramenta global

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

Se tiver feito um link de símbolo, você também precisará removê-lo:

sudo rm /usr/local/bin/TOOLCOMMAND

Ferramentas locais

As ferramentas locais têm escopo por árvore de subdiretório, por usuário. Quando executadas com privilégios elevados, as ferramentas locais compartilham um ambiente de usuário restrito com o ambiente com privilégios elevados. No Linux e no macOS, isso resulta em arquivos sendo definidos com acesso somente para o usuário raiz. Se o usuário voltar para uma conta restrita, ele não poderá acessar ou gravar arquivos. Então, não é recomendado instalar as ferramentas que exigem elevação como ferramentas locais. Em vez disso, use a opção --tool-path e as diretrizes anteriores de ferramentas globais.

Elevação durante o desenvolvimento

Durante o desenvolvimento, talvez você precise de acesso com privilégios elevados para testar seu aplicativo. Esse cenário é comum para aplicativos de IoT, por exemplo. É recomendável que você compile o aplicativo sem elevação e, em seguida, execute-o com elevação. Há alguns padrões, como abaixo:

• Usando o executável gerado (fornece o melhor desempenho de inicialização):

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

• O uso do comando dotnet run com o —no-build sinalizador para evitar a geração de novos binários:

  dotnet build
  sudo dotnet run --no-build
  

Confira também

• Visão geral das ferramentas do .NET