Läs på engelska

Dela via


Förhöjd åtkomst för dotnet-kommandon

Metodtips för programvaruutveckling hjälper utvecklare att skriva programvara som kräver minst behörighet. Vissa program, till exempel verktyg för prestandaövervakning, kräver dock administratörsbehörighet på grund av operativsystemregler. Följande vägledning beskriver scenarier som stöds för att skriva sådan programvara med .NET Core.

Följande kommandon kan köras förhöjda:

  • dotnet tool kommandon, till exempel installation av dotnet-verktyget.
  • dotnet run --no-build
  • dotnet-core-uninstall

Vi rekommenderar inte att du kör andra kommandon som är upphöjda. I synnerhet rekommenderar vi inte utökade kommandon som använder MSBuild, till exempel dotnet restore, dotnet build och dotnet run. Det primära problemet är problem med behörighetshantering när en användare övergår fram och tillbaka mellan roten och ett begränsat konto efter att ha utfärdat dotnet-kommandon. Som begränsad användare kanske du inte har åtkomst till filen som skapats av en rotanvändare. Det finns sätt att lösa den här situationen, men de är onödiga att komma in i från början.

Du kan köra kommandon som rot så länge du inte övergår fram och tillbaka mellan roten och ett begränsat konto. Docker-containrar körs till exempel som rot som standard, så de har den här egenskapen.

Installation av globalt verktyg

Följande instruktioner visar det rekommenderade sättet att installera, köra och avinstallera .NET-verktyg som kräver utökade behörigheter för att köra.

Installera det globala verktyget

Pakettillgångar ska installeras på en skyddad plats med hjälp av --tool-path alternativet . Den här separationen undviker att dela en begränsad användarmiljö med en upphöjd miljö.

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

/usr/local/share/dotnet-tools skapas med behörigheten drwxr-xr-x. Om katalogen redan finns använder du ls -l kommandot för att kontrollera att den begränsade användaren inte har behörighet att redigera katalogen. I så fall använder du sudo chmod o-w -R /usr/share/dotnet-tools kommandot för att ta bort åtkomsten.

Kör det globala verktyget

Alternativ 1 Använd den fullständiga sökvägen med sudo:

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

Alternativ 2 Lägg till symbollänken för verktyget en gång per verktyg:

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

Och kör med:

Bash
sudo TOOLCOMMAND

Avinstallera det globala verktyget

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

Om du har skapat en symbollänk måste du också ta bort den:

Bash
sudo rm /usr/local/bin/TOOLCOMMAND

Lokala verktyg

Lokala verktyg är begränsade per underkatalogträd, per användare. När körningen är förhöjd delar lokala verktyg en begränsad användarmiljö till den upphöjda miljön. I Linux och macOS resulterar detta i att filer ställs in med åtkomst endast för rotanvändare. Om användaren växlar tillbaka till ett begränsat konto kan användaren inte längre komma åt eller skriva till filerna. Därför rekommenderas inte installation av verktyg som kräver utökade privilegier som lokala verktyg. Använd i stället alternativet --tool-path och de tidigare riktlinjerna för globala verktyg.

Utökade privilegier under utveckling

Under utvecklingen kan du behöva förhöjd åtkomst för att testa ditt program. Det här scenariot är vanligt för till exempel IoT-appar. Vi rekommenderar att du skapar programmet utan utökade privilegier och sedan kör det med utökade privilegier. Det finns några mönster, enligt följande:

  • Använda genererad körbar fil (det ger bästa startprestanda):

    .NET CLI
    dotnet build
    sudo ./bin/Debug/netcoreapp3.0/APPLICATIONNAME
    
  • Använd kommandot dotnet run med —no-build flaggan för att undvika att generera nya binärfiler:

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

Se även