ドッキングウィンドウは、uidのドッキングウィンドウコンテナ理解し、ユーザー権利の問題のボリュームをマウントする
ディレクトリ
の問題に遭遇する
の理由の
UIDの容器共有ホストを
使用すると、ユーザーを指定しない場合は、内側容器のデフォルトのrootユーザーが実行するには
、内部ユーザーと外部ユーザーアクセス許可の同じコンテナを
必須容器執行当局のデータボリュームに対応することを確認し、マウント
より顕著デモ
参照
ドッカーボリュームがユーザ権限をマウントし、UID容器はドッカーを理解しました
ドッキングウィンドウのボリュームの使用データボリュームをマウント初めに、問題は、多くの場合、権限がありません。
ここでは、ユーザが直面する問題を介して容器のUID内部と外部の関係を、使用するドッキングウィンドウコンテナを理解し理解し、マッピングするためにUIDです。
遭遇した問題
プロジェクトのニーズのローカル・ノードは、インストールNPM実行するためにドッキングウィンドウを使用してコンパイルします。
sudoのドッキングウィンドウの実行-it --rm --nameライアン\
-v pwd：pwd \
-w pwd ノード
NPMインストール--registry = https://registry.npm.taobao.org
これは、ルートへのインストール、アクセス権node_modulesファイルの後に見ることができます。その後、ユーザーとして私たちは、このファイルを削除する権限がありません。
なぜファイルのパーミッションのドッキングウィンドウの出力は、ルートでしょうか？
理由
特にユーザーは、rootとして実行するデフォルトを指定されていない場合は、時間は、ドッカーコンテナを実行しています。Dockerfileは、当社のノードに反映ユーザに指定されていません。
ユーザIDの実行の容器は0が出力ファイル権限、0です。
以下参考ドッカー容器にどのようにuidとgidの仕事を理解します
UIDコンテナのシェアは、ホストの
最初のuid、gidの実装を理解しています。Linuxカーネルは、uidとgidを管理するための責任がある、と当局によって要求された場合、カーネルレベルのシステムコールによって決定されます。
プロセスがファイルを書き込もうとすると、例えば、カーネルはプロセスがこのファイルを変更する権限を持っているかどうかを判断するために、ユーザーのuidとgidの創造のプロセスをチェックします。
ユーザ名が、UIDの使用はありません。
ホスト上で実行されている、とドッキングウィンドウコンテナは、まだカーネルだけであるとき。コンテナがホストカーネルを共有し、すべてのUIDとGIDは同じコアによって制御されています。
なぜコンテナのユーザ名とホストカーネルは必ずしも同じではないでしょうか？例えば、ユーザはスーパーセットスーパーセットコンテナと呼ばれ、マシンは、ユーザーのスーパーセットを行います。usernameはLinuxカーネルの一部ではないためです。簡単に言えば、ユーザ名がUIDのマッピングです。
しかし、アクセス制御によればuidですし、ユーザ名ではありません。
一般的なLinuxツールに表示されたユーザ名（グループ名）ためのカーネルの一部ではありませんが、外部ツール（/ etc / passwdファイル、LDAP、ケルベロスなど）によって管理されています。だから、あなたは別のユーザー名が表示されることがありますが、あなたは同じUID / GIDのための異なる権限を持つことができない、でも異なるコンテナ内部
あなたは、デフォルトで実行するには、rootユーザーを使用して、ユーザー、容器の内部を指定しない場合
、我々はミラーノードを使用し続けて、あなたはgithubのでDockerfileを表示することができます。作成した
ユーザノード1000のUIDを、しかし実行するユーザーを指定しませんでした。
ドッキングウィンドウは、-d --rm --nameライアンノード睡眠実行無限大
なので、その背景血管睡眠プログラムを私はライアン（UID = 1000）に対して実行ユーザーを。
私たちが見ることができ、ユーザプロセスの実行は、外側容器がルートで眠ります。容器の内部は、ユーザが0（ルート）である。ユーザがドッカーランライアンを行っている間。
言い換えれば、私は、rootとしてコマンドを実行する一般ユーザに行くことができました。これは非常に怖い表情に見えます。
コンテナ内部ユーザの外部ユーザーと同じ権限を
許可がUIDによって判断されます。次のテストは、ユーザーがファイルのUIDに同じUID帰属を変更することができます。
ホストユーザーライアンがあります。
ミラーリングDockerfile使用するだけのノードは、ユーザーノード1000個のを定義しています。
私たちは地元、ホーム加入者ライアンに文書を書きました
次いで、容積負荷を介して、ユーザ指定操作1000と、コンテナ・ノードを起動します。
1000年-uドッキングウィンドウの実行-d --rm --nameテスト：1000 -v $（PWD）：/ tmpのノード睡眠無限大
ユーザがライアン（睡眠の別のインスタンスがルートユーザーの前に行われ、削除されない）であり、コンテナプロセス外睡眠を実行見ることができます。
すなわち、ドッキングウィンドウの実行-uユーザーが実行しているホストドッキングウィンドウのコマンドを指定することができ、プロセス-u uidのは、所有者の実際の動作ドッカ指定されています。
そして、あなたがマウントされたファイルを変更することができるかどうか、容器の内側に行きます。
あなたが見ることができる、我々はショーは、ファイルの所有者は、コンテナ内のuid = 1000人のユーザーであるノード、あるマウントされています。そして、表示および変更する権限を持っています。
その後、我々は1000個のノード自然にはuid =属し、容器の内側に、このBをファイルbを書きます。容器の外を見てみましょう：
同様に、外側のライアン1000年のショーのユーザーbのUID =所属の容器、およびビューへのアクセス権を持っているし、変更します。
だから、それはコンテナとそれに対応するシェアUID許可の内側と外側の両方を証明することができます。
私たちは、パフォーマーの権利を確保し、対応する容器の容積データマウントする必要があり
、この論文の最初の質問は、コンテナの権限として、パフォーマーであるが、異なるデータボリュームをマウントします。コンテナ内で実行すると、UID = 0、データ量に依存するとUID =ライアン1000です。最終的にはその普通のユーザーがアクセスできないことを、ルートにアップグレード書き込みデータボリュームにコンテナファイルのパーミッションをリードします。
あなたはコンテナにルート・ファイルをマウントし、コンテナ内部実行uidが0でない場合は、エラーが権限を持っていません。私はこの記事で、この問題に遭遇したとき、NPMキャッシュをマウントします。
より多くの明白なデモ
デモ上記は、共有ファイルのアクセス権を得るため、UID = 1000人のユーザがあるので、非常に調和のとれたばかりのホストマシンとコンテナです。次に、より重要なテストのデモ。
ホストマシンとコンテナは、私たちのコンテナを実行するために、= 1111 1111 uidをされていません。
ドッキングウィンドウの実行-d --rm --nameデモ-u 1111：1111 -v $（PWD）：/ tmpのノード睡眠無限大
現在のデータボリュームは、ファイルの所有権をファイルおよびディレクトリANY_USERがあり、UID = 1000、DIR ANY_USER誰でも書くことができます
とのuid = 1111実行して、コンテナを実行するために
、上のコンテナログ内のデータ量を表示し、既得ファイルやディレクトリANY_USERを見つけましたUID = 1000ノード（UIDマッピング）で
内側容器は、ユーザーのuid = 1111、私は名前を持っていない！、何のユーザ名を表示、ない家ではないので。
何の権威を示唆していない、コンテナへの書き込み内部のデータボリュームを実行します。（権利データの量が1000 = UIDであるため）
、容器（777）内の共通データ領域内のファイルに書き込む。
次に、外側の容器の性能を見て：
実際のデータファイルは、内容の読み、書かれている
ファイルのアクセス権がコンテナ1111のuidに書き込まれます。ホストは、このユーザーを持っていないとして、uidが直接表示
プロセスを表示、プロセスは、コンテナ内に見つけることができる1111
-uユーザーはコンテナ内の実行、およびコンテナ外部のホストユーザー・プロセスを指定し、データ量により許可を書かれた同じコンテナでもあるされていますこれが指定されています。
このように、内側と外側のコンテナの対応関係を理解するデモ簡単には、UID。データボリュームをマウントするときに我々が理解した後は、アクセス権の問題は表示されません。
セキュリティ上の問題のため、通常はコンテナを実行するにはrootを使用することをお勧めしません。
リファレンスは、
ドッカーの中uidとgid作業方法を理解コンテナが
ドッキングウィンドウコンテナのuidとgidを高く評価しました
著者：@Ryanミャオ族
このリンク：https://www.cnblogs.com/woshimrf/p/understand-docker-uid.html