Бөлісу құралы:

Повышенный доступ для команд dotnet

Рекомендации по разработке программного обеспечения помогут разработчикам писать программное обеспечение, требующее минимального количества привилегий. Однако для некоторых программ, таких как средства мониторинга производительности, требуется разрешение администратора из-за правил операционной системы. В следующем руководстве описаны поддерживаемые сценарии написания такого программного обеспечения с помощью .NET Core.

Следующие команды можно выполнить с повышенными привилегиями:

  • dotnet tool команды, такие как dotnet tool install.
  • dotnet run --no-build
  • dotnet-core-uninstall

Не рекомендуется выполнять другие команды с повышенными привилегиями. В частности, мы не рекомендуем повышать привилегии при выполнении команд, использующих MSBuild, таких как dotnet restore, dotnet build и dotnet run. Основная проблема заключается в проблемах управления разрешениями при переходе пользователя между корнем и ограниченной учетной записью после выдачи команд dotnet. Вы можете обнаружить, что у вас, как пользователя с ограниченными правами, нет доступа к файлу, созданному пользователем root. Есть способы решения этой ситуации, но изначально в неё не стоит вовлекаться.

Вы можете выполнять команды с правами суперпользователя, если вы не переходите от него к ограниченной учетной записи и обратно. Например, контейнеры Docker выполняются в качестве корневого каталога по умолчанию, поэтому они имеют эту характеристику.

Установка инструмента на глобальном уровне

Приведенные ниже инструкции демонстрируют рекомендуемый способ установки, запуска и удаления средств .NET, требующих повышенных разрешений для выполнения.

Установка средства

Если папка %ProgramFiles%\dotnet-tools уже существует, проверьте, имеет ли группа "Пользователи" разрешение на запись или изменение этого каталога:

  • Щелкните правой кнопкой мыши папку %ProgramFiles%\dotnet-tools и выберите "Свойства". Откроется диалоговое окно "Общие свойства ".
  • Перейдите на вкладку "Безопасность ". В разделе "Имена групп" или пользователей проверьте, имеет ли группа "Пользователи" разрешение на запись или изменение каталога.
  • Если группа "Пользователи" не может написать или изменить каталог, используйте другое имя каталога при установке средств, а не dotnet-tools.

Чтобы установить средства, выполните следующую команду в командной строке с повышенными привилегиями. Она создаст папку dotnet-tools во время установки.

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

Запустите глобальный инструмент

Вариант 1 Используйте полный путь с командной строкой с повышенными привилегиями:

"%ProgramFiles%\dotnet-tools\TOOLCOMMAND"

Вариант 2 Добавьте только что созданную папку %Path%. Эту операцию необходимо выполнить только один раз.

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

И запустите следующим образом:

TOOLCOMMAND

Удалить глобальный инструмент

В командной строке с повышенными привилегиями введите следующую команду:

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

Локальные средства

Локальные инструменты определены для каждого дерева подкаталогов и каждого пользователя. При запуске в повышенном режиме локальные средства разделяют ограниченную пользовательскую среду с средой с повышенными привилегиями. В Linux и macOS это приводит к настройке файлов с доступом только для корневого пользователя. Если пользователь переключается обратно на ограниченную учетную запись, пользователь больше не может получать доступ к файлам или записывать их. Поэтому не рекомендуется устанавливать средства, требующие повышения прав, как локальные инструменты. Вместо этого используйте --tool-path параметр и предыдущие рекомендации для глобальных инструментов.

Повышение уровня во время разработки

Во время разработки может потребоваться повышенный доступ для тестирования приложения. Этот сценарий распространен для приложений Интернета вещей, например. Рекомендуем сначала создать приложение без повышения разрешений, затем запустить его с повышением разрешений. Существует несколько шаблонов, как показано ниже.

  • Используя созданный исполняемый файл (он обеспечивает лучшую производительность запуска):

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

  • Используйте команду dotnet run с флагом —no-build , чтобы избежать создания новых двоичных файлов:

    dotnet build
sudo dotnet run --no-build

См. также

  • Last updated on