dotnet コマンドの特権アクセス
- [アーティクル]
-
-
ソフトウェア開発のベスト プラクティスでは、最小限の特権を要求するソフトウェアを記述するように開発者に指導しています。 しかしながら、パフォーマンス監視ツールなど、一部のソフトウェアでは、オペレーティング システムのルールに起因し、管理者権限を必要とします。 次のガイダンスでは、そのようなソフトウェアを .NET Core で開発する場合にサポートされるシナリオを紹介しています。
次のコマンドは管理者特権で実行できます。
その他のコマンドを管理者特権で実行することはお勧めしません。 具体的には、dotnet restore、dotnet build、dotnet run など、MSBuild を使用するコマンドで特権昇格を推奨していません。 主な問題は、dotnet コマンドの実行後、ルートと制限付きアカウントの間をユーザーが行ったり来たりするという、アクセス管理の問題です。 制限付きユーザーであれば、ルート ユーザーが作成したファイルにアクセスできません。 この状況を解決する方法はありますが、このような状況になることがそもそも不要です。
ルートと制限付きアカウントの間を行ったり来たりしない限り、ルートでコマンドを実行できます。 たとえば、Docker コンテナーは既定でルートとして実行するため、この特性があります。
次の手順は、実行に特権昇格を必要とする .NET ツールをインストール、実行、アンインストールするときの推奨方法を示しています。
フォルダー %ProgramFiles%\dotnet-tools
が既に存在する場合、次を行い、そのディレクトリを記述または変更する許可が "Users" グループに与えられているかどうかを確認します。
%ProgramFiles%\dotnet-tools
フォルダーを右クリックし、 [プロパティ] を選択します。 [共通プロパティ] ダイアログ ボックスが開きます。
- [セキュリティ] タブを選択します [グループ名またはユーザー名] で、"Users" グループにディレクトリを記述または変更する権限が与えられているかどうかを確認します。
- "Users" グループでディレクトリを記述または変更できない場合、dotnet-tools 以外のツールをインストールするとき、別のディレクトリ名を使用します。
ツールをインストールするには、管理者特権のプロンプトで次のコマンドを実行します。 インストール中、dotnet-tools フォルダーが作成されます。
dotnet tool install PACKAGEID --tool-path "%ProgramFiles%\dotnet-tools".
オプション 1 管理者特権プロンプトで完全パスを使用します。
"%ProgramFiles%\dotnet-tools\TOOLCOMMAND"
オプション 2 新しく作成したフォルダーを %Path%
に追加します。 この操作を行うのは 1 回だけです。
setx Path "%Path%;%ProgramFiles%\dotnet-tools\"
次で実行します。
TOOLCOMMAND
管理者特権プロンプトで次のコマンドを入力します。
dotnet tool uninstall PACKAGEID --tool-path "%ProgramFiles%\dotnet-tools"
パッケージ アセットは --tool-path
オプションを使用して保護された場所にインストールする必要があります。 このように分けることにより、制限付きユーザー環境が特権環境と共有されることを回避できす。
sudo dotnet tool install PACKAGEID --tool-path /usr/local/share/dotnet-tools
/usr/local/share/dotnet-tools
は drwxr-xr-x
アクセス許可で作成されます。 ディレクトリが既に存在する場合は、ls -l
コマンドを使用して、制限付きユーザーにディレクトリを編集するアクセス許可がないことを確認します。 ある場合は、sudo chmod o-w -R /usr/share/dotnet-tools
コマンドを使用してそのアクセス許可を削除します。
オプション 1 sudo で完全なパスを使用します。
sudo /usr/local/share/dotnet-tools/TOOLCOMMAND
オプション 2 ツールごとに 1 回、ツールのシンボルのリンクを追加します。
sudo ln -s /usr/local/share/dotnet-tools/TOOLCOMMAND /usr/local/bin/TOOLCOMMAND
次で実行します。
sudo TOOLCOMMAND
sudo dotnet tool uninstall PACKAGEID --tool-path /usr/local/share/dotnet-tools
シンボルのリンクを作成した場合は、それも削除する必要があります。
sudo rm /usr/local/bin/TOOLCOMMAND
パッケージ アセットは --tool-path
オプションを使用して保護された場所にインストールする必要があります。 このように分けることにより、制限付きユーザー環境が特権環境と共有されることを回避できす。
sudo dotnet tool install PACKAGEID --tool-path /usr/local/share/dotnet-tools
/usr/local/share/dotnet-tools
は drwxr-xr-x
アクセス許可で作成されます。 ディレクトリが既に存在する場合は、ls -l
コマンドを使用して、制限付きユーザーにディレクトリを編集するアクセス許可がないことを確認します。 ある場合は、sudo chmod o-w -R /usr/share/dotnet-tools
コマンドを使用してそのアクセス許可を削除します。
オプション 1 sudo で完全なパスを使用します。
sudo /usr/local/share/dotnet-tools/TOOLCOMMAND
オプション 2 ツールごとに 1 回、ツールのシンボルのリンクを追加します。
sudo ln -s /usr/local/share/dotnet-tools/TOOLCOMMAND /usr/local/bin/TOOLCOMMAND
次で実行します。
sudo TOOLCOMMAND
sudo dotnet tool uninstall PACKAGEID --tool-path /usr/local/share/dotnet-tools
シンボルのリンクを作成した場合は、それも削除する必要があります。
sudo rm /usr/local/bin/TOOLCOMMAND
ローカル ツールの範囲は、サブディレクトリごとに/ユーザーごとに設定されます。 管理者特権で実行するとき、ローカル ツールによって、制限付きユーザー環境が特権環境に与えられます。 Linux と macOS では、この結果、ファイルが root ユーザー専用アクセスで設定されます。 ユーザーが制限付きアカウントに戻ると、そのファイルにアクセスしたり、書き込んだりできなくなります。 そのため、特権昇格を必要とするツールをローカル ツールとしてインストールすることは推奨されません。 その代わり、--tool-path
オプションとグローバル ツールに関する前述のガイドラインをご利用ください。
開発中、アプリケーションをテストする目的で管理者特権が必要になることがあります。 これは、たとえば、IoT アプリで一般的なシナリオです。 Microsoft では、特権昇格なしでアプリケーションを開発し、管理者特権でそれを実行することをお勧めしています。 次のようにいくつかのパターンがあります。
生成された実行可能ファイルを使用する (最高のスタートアップ パフォーマンスが与えられます):
dotnet build
sudo ./bin/Debug/netcoreapp3.0/APPLICATIONNAME
dotnet run コマンドを使用するとき、—no-build
フラグを指定し、新しいバイナリの生成を回避します。
dotnet build
sudo dotnet run --no-build