権限拒否エラーのため、Sudo mkdirが失敗する

権限拒否エラーのため、Sudo mkdirが失敗する

私はいくつかのファイルをある場所から別の場所にコピーするスクリプトを書いたが、ソースフォルダに対する権限がなかったので、sudoを使って実行してみました。問題は、ターゲットフォルダの作成が失敗することです。以下は簡単なテストケースです。

私のホームディレクトリでは、次のことが機能します。

mkdir testDir

ただし、権限拒否エラーのため失敗します。

sudo mkdir testDir2

私のホームディレクトリには755の権限があり、私のものです。

私は走って、sudo groups確かにそのrootグループがそこにあることを知っていましたが、奇妙なことにそうではusersありませんでした。また、groups自分で実行すると、私はsudoグループに属していないことを示しています。

どんなアイデアがありますか? sudoで実行するとホームフォルダに書き込めないのはなぜですか?

答え1

これは、NFS サーバーの「ルートスカッシング」によって発生します。マニュアルページでexports(5)(ハイライト):

nfsd は、各 NFS RPC 要求で提供される uid および gid に基づいて、サーバーシステム上のファイルへのアクセスを制御します。ユーザーが期待する一般的な動作は、通常のファイルシステムのようにサーバー上のファイルにアクセスできることです。これを行うには、クライアントとサーバーシステムで同じuidとgidを使用する必要があります。これは必ずしも正しいわけではなく、常に望ましいものではありません。

通常、NFSサーバー上のファイルにアクセスするときに、クライアントシステムのrootユーザーがrootと見なされることは望ましくありません。このため、uid 0 は通常、いわゆる匿名または人間 uid という別の ID にマップされます。この動作モード(「ルートスカッシュ」と呼ばれる)はデフォルトモードであり、no_root_squashを使用してオフにすることができます。

つまり、sudoNFS クライアントのルートが (実行時になど) NFS サーバーのルートと同じ方法でファイルとファイルの属性を変更できるようにすることは、通常セキュリティ上危険です。これは効果的にクライアントのルートをサーバーのルートと同じにし、悪意のあるクライアントがサーバーを制御できるようにします。

~からRHEL 6 セキュリティガイド:

no_root_squash を使用すると、リモート root ユーザーが共有ファイルシステム上のすべてのファイルを変更でき、他のユーザーが誤って実行するようにトロイの木馬に感染したアプリケーションを残すことができます。

関連情報