Moby: ルート以外のユーザーとしてボリュームをマウントする機能を追加

ボリュームをバインドマウントする前に（ホスト側で） chown 、動作します。
その場合、次のことができます。

mkdir /tmp/www
chown 101:101 /tmp/www
docker run -v /tmp/www:/var/www ubuntu stat -c "%U %G" /var/www

（ 101:101がコンテナー内のwww-dataユーザーのUID：GIDであると想定します。）

もう1つの可能性は、bind-mountを実行してから、コンテナー内でchownを実行することです。

@mingfang chownは機能しませんか？

このためのショートカットがあると便利です。 ボリュームにパーミッションを設定するだけのrunスクリプトを書いていることがよくあります。

https://github.com/orchardup/docker-redis/blob/07b65befbd69d9118e6c089e8616d48fe76232fd/run

chownの権利がない場合はどうなりますか？

ボリュームがchownのヘルパースクリプトでこの問題を解決できますか？ このスクリプトは、DockerfileのENTRYPOINTにすることができます。

いいえと言えますか？ユーザーにヘルパースクリプトを追加するように強制します

#!/bin/sh
chown -R redis:redis /var/lib/redis
exec sudo -u redis /usr/bin/redis-server

（あなたの例を@bfirshに感謝します）

かなりひどいです。

これは、コンテナを目的のredisユーザーとして実行するのではなく、rootとして開始する必要があることを意味します。 （ @aldanorがほのめかしているように）

これは、ユーザーが次のようなことを実行できないことを意味します。

docker run -v /home/user/.app_cfg/ -u user application_container application :(

それを機能させる方法は1つありますが、Dockrfile内で事前に準備する必要があります。

RUN mkdir -p /var/lib/redis ; chown -R redis:redis /var/lib/redis
VOLUME ["/var/lib/redis"]
ENTRYPOINT ["usr/bin/redis-server"]
USER redis

（私はこの例をテストしませんでした。クロムコンテナで作業していて、それが_separate_X11コンテナに表示されます....）

そしてもちろん、そのメソッドは直接新しいボリュームに対してのみ機能し、バインドは機能しません
マウントまたはボリューム-ボリュームから。 ;）

さらに、 volumes-fromを使用する複数のコンテナーは、同じユーザーに対して異なるuid / gidを持つため、作業も複雑になります。

@ SvenDowideit @ tianonそのメソッドも機能しません。 完全な例：

FROM ubuntu
RUN groupadd -r redis    -g 433 && \
useradd -u 431 -r -g redis -d /app -s /sbin/nologin -c "Docker image user" redis 
RUN mkdir -p /var/lib/redis
RUN echo "thing" > /var/lib/redis/thing.txt
RUN chown -R redis:redis /var/lib/redis
VOLUME ["/var/lib/redis"]
USER redis
CMD /bin/ls -lah /var/lib/redis

-vボリュームがある場合とない場合の2回の実行：

bash-3.2$ docker run -v `pwd`:/var/lib/redis voltest 
total 8.0K
drwxr-xr-x  1 root root  102 Aug  7 21:30 .
drwxr-xr-x 28 root root 4.0K Aug  7 21:26 ..
-rw-r--r--  1 root root  312 Aug  7 21:30 Dockerfile
bash-3.2$ docker run  voltest 
total 12K
drwxr-xr-x  2 redis redis 4.0K Aug  7 21:30 .
drwxr-xr-x 28 root  root  4.0K Aug  7 21:26 ..
-rw-r--r--  1 redis redis    6 Aug  7 21:26 thing.txt
bash-3.2$ 

これで解決できる問題に直面しています（私は思います）。 開発者のホームディレクトリ用にNFS共有があります。 開発者は/home/dev/git/projectをDockerにマウントしたいのですが、ルートスカッシュが有効になっているためできません。

これにより、rootが/home/dev/git/projectにアクセスできなくなるため、Dockerマウント/home/dev/git/projectを実行しようとすると、 lstat permission deniedエラーが発生します。

@frankampこれは、dockerの現在の設定が、Docker自身の制御の範囲外にあるホストのものを変更しないことであるためです。

「VOLUME」の定義は、 -v pwd`：/ var / lib / reds`によって上書きされています。
ただし、2回目の実行では、/ var / lib / dockerに作成されたDocker制御のボリュームを使用しています。 コンテナーが起動すると、dockerはデータをイメージからボリュームにコピーし、ボリュームが指定されたdirのuid：gidを使用してボリュームを変更します。

ここでできることがたくさんあるかどうかはわかりませんが、残念ながら、バインドマウントは（私が知る限り）別のuid / gidとしてのマウントをサポートしていません。

これに対する私の解決策は、SvenDowideitが上記で行ったことを実行することでした（新しいユーザーを作成し、dockerfileで前もってchownします）が、ホストボリュームをマウントする代わりに、データ専用コンテナーを使用し、マウントしたいホストボリュームをにコピーしますtar cf - . | docker run -i --volumes-from app_data app tar xvf - -C /dataのコンテナ。 https://github.com/docker/docker/pull/13171がマージされると（そしてdocker cpは両方の方法で機能します）、これは少し簡単になりますが、おそらく-v host_dir:container_dirの代わりになる可能性があります-vc host_dir:container_dir （ボリュームコピーの場合はvc）で、host_dirの内容がデータコンテナにコピーされます。 コピーされたファイルがコンテナユーザーの権限を継承する理由/方法を理解しているとは言えませんが、私が言えることから、これは移植性を損なうことのない、私が思いついた唯一の合理的な解決策です。

aclはどうですか？

修正または回避策はありますか？ OpenShiftで同じ問題が発生し、マウントされたフォルダーはroot：rootによって所有され、事前に作成されたイメージは機能しません。

私も回避策を探しています。 マウントされたすべてのボリュームがrootによって所有されている場合、 root以外のユーザーでDockerコンテナーを実行することはできません。

さて、あなたはs6-overlayを試すことができます。 これには、これらの種類の問題の回避を支援することを特に目的とした機能が含まれています。

@ dreamcat4 ：ポインタをありがとう。 所有権と権限の修正は興味深い回避策のように思えますが、それを機能させるには、Dockerコンテナをrootとして実行する必要はありませんか？

@ brikis98はいそれは本当です。 ただし、s6-overlayにはさらに別の機能があり、サーバー/デーモンを起動するときにアクセス許可を再度ドロップできます。

@ dreamcat4ああ、やった、ありがとう。

私はコンテナの内側と外側で同じuid / gidを持っており、これが私が得るものです：

nonroot$ ls -l .dotfiles/
ls: cannot access .dotfiles/byobu: Permission denied
ls: cannot access .dotfiles/config: Permission denied
ls: cannot access .dotfiles/docker: Permission denied
ls: cannot access .dotfiles/vim: Permission denied
ls: cannot access .dotfiles/bashrc: Permission denied
ls: cannot access .dotfiles/muse.yml: Permission denied
ls: cannot access .dotfiles/my.cnf: Permission denied
ls: cannot access .dotfiles/profile: Permission denied
total 0
-????????? ? ? ? ?            ? bashrc
d????????? ? ? ? ?            ? byobu
d????????? ? ? ? ?            ? config
d????????? ? ? ? ?            ? docker
-????????? ? ? ? ?            ? muse.yml
-????????? ? ? ? ?            ? my.cnf
-????????? ? ? ? ?            ? profile
d????????? ? ? ? ?            ? vim
nonroot$ ls -l .ssh
ls: cannot access .ssh/authorized_keys: Permission denied
total 0
-????????? ? ? ? ?            ? authorized_keys
nonroot$

@darkermatter別の問題を開いていただけませんか。

問題ではありませんが、これはここでは関係ありませんか？

@darkermatterこれは機能のリクエストであり、バグレポートではありません。ケースを他のケースと混合すると、ディスカッションをフォローするのが難しくなります。また、問題が直接関連していない可能性があります。

@thaJeztahええと、 @ frankampや他の人たちがやったように、私は単にDockerfile内でchmodなどを実行した後に何が起こるかを示していました。 バグレポートとして提出しますが、この議論に関連しています。

@ebuchmanが提案したものと同様に、ホストボリュームをコピーせずに、最初にデータ専用コンテナを作成できます。
開始時にrootとしてchown 1000:1000 /volume-mount 。
たとえば、docker composev2構文

version: '2'
services:
  my-beautiful-service:
    ...
    depends_on:
      - data-container
    volumes_from:
      - data-container

  data-container:
    image: same_base_OS_as_my-beautiful-service
    volumes:
      - /volume-mount
    command: "chown 1000:1000 /volume-mount"

このようにして、コンテナをroot以外のユーザーとして実行できます。 データ専用コンテナは1回だけ実行されます。
my-beautiful-serviceが使用するuidとgidを事前に知っていると仮定します。 通常は1000,1000です。

（1.11で） docker volume createで使用するボリュームのマウントオプションを指定できるので、これは閉じる準備ができているように思えます。

バインドマウントではサポートされていないため、uid / gidを直接指定することはできませんが、新しいマウントoptsで使用できる多くのファイルシステムはuid / gidoptsで動作します。

コンテナ内にCIFSドライブをマウントしたい場合でも、問題は解決しないと思いますが、それは別のチケットである必要がありますか？

@ michaeljs1990これは、コンテナーごとではなく、実行できます（必要なuid / gidコンボごとに個別のボリュームを作成する場合を除く）。

@ cpuguy83 、この問題を回避するためにdocker volume createをどのように使用する必要があるかを明確にしていただけますか？

今日、docker 1.11でこの問題が発生し、マウントされたドライブ上のファイルに書き込めるようにdockerイメージを説得するために苦痛な再調整を行う必要がありました。 他の人に説明しようとするのはもちろんのこと、二度とそれをする必要がなければ、本当にいいでしょう。

これがあなたが求めているものかどうかはわかりませんが...

FROM busybox
RUN mkdir /hello && echo hello > /hello/world && chown -R 1000:1000 /hello

「テスト」という名前の画像の上にビルド

$ docker volume create --name hello
$ docker run -v hello:/hello test ls -lh /hello

上記の例の/helloと/hello/worldはどちらも、1000：1000が所有します。

そうですか。 それで、私は似たようなことをしましたが、少し違うので、共有する価値があるかもしれません。 基本的に、コンテナ外のユーザーのUID、GID、ユーザー名、およびグループを共有するユーザーをDockerfileに追加しました。 すべての<...>は、関連する値に置き換えられたものです。

FROM <some_image>
RUN groupadd -g <my_gid> <my_group> && \
    useradd -u <my_uid> -g <my_gid> <my_user>

この後、 USERを使用するか、後の時点でsuを使用して切り替えることができます（たとえば、エントリポイントスクリプトまたはシェルを使用する場合）。 これにより、作成したのと同じユーザーであるため、マウントされたボリュームに書き込むことができました。 さらに、コンテナ内でchownを使用して、関連するものに対する権限があることを確認できます。 また、 sudoをインストールすることは、これを行う場合にも一般的に賢明な方法です。

それは問題を解決しますが、これはすべてのユーザーのために行う必要があるので、私はそれが好きかどうかわかりません。 また、私はものをハードコーディングしましたが（うん！）、テンプレートを使用してこれを少しスムーズにすることができます。 このシムはどういうわけかdocker runに吸収されるのだろうか。 これを行うためのより良い方法がすでにある場合、私はそれが何であるかを知ることに非常に興味があります。

ホストユーザーのuids / gidsをコンテナーユーザーのuids / gidsに--userns-remapでマップするオプションがあります。 個人的には試していません。 このトピックに関する良い議論を参照してくださいhttp://stackoverflow.com/questions/35291520/docker-and-userns-remap-how-to-manage-volume-permissions-to-share-data-betwee 。

@ cpuguy83 ：

バインドマウントではサポートされていないため、uid / gidを直接指定することはできませんが、新しいマウントoptsで使用できる多くのファイルシステムはuid / gidoptsで動作します。

uid / gid引数を受け入れることができると考えているファイルシステムは何ですか？ 私はFATができることを知っていますが、それはこのスレッドで提案されている他のものと同じようにハッキーな感じがします。

IMO、Dockerには2つのオプションがあります。

1. 指定されたユーザー/グループとしてボリュームをマウントするための公式サポート（コンテナー内で定義されたユーザー/グループ名を使用し、ホストがコンテナーの内部に関するこの知識を持っている必要はありません）。
2. または... USERディレクティブ（および関連するランタイムフラグ）を削除します。

rootが所有するボリュームのみをマウントできる一方で、root以外のユーザーとして実行できることは、機能の誤りです。 ホストとコンテナ間でのuid / gidの共有は、もう1つの誤った機能です。

@mehaaseボリュームは、コンテナー内のパスに既に存在するものすべての所有権を取得します。 コンテナ内の場所がrootによって所有されている場合、ボリュームはrootになります。 コンテナ内の場所が他の誰かによって所有されている場合、ボリュームはそれを取得します。

これに対するある種の回避策は素晴らしいでしょう。 コンテナーが特にそれを予期しない限り、アクセス許可を設定するカスタムDockerfileを作成せずに、elasticsearch、redis、couchDBなどの標準コンテナーにボリュームを追加することは_非常に_困難になります。 これにより、ほとんどの場合、docker-composeのdocker run -vコマンドまたはvolume:ディレクティブが役に立たなくなります。

@chrisfosterelliなぜ役に立たないのですか？ 使用する予定のファイル/ディレクトリの所有権を設定することは珍しいことではないと思います。

@ cpuguy83権限とボリュームを設定するカスタムDockerfileを使用せずに所有権を設定することはできないように思われるため、ボリュームの定義には役立たないと考えられます。 必要に応じて、コンテナをホストファイルシステムにバインドしていません。

@chrisfosterelliただし、これらすべての標準Dockerfileには、すでにアクセス許可が設定されている必要があります。

@chrisfosterelliが言おうとしているのは@ cpuguy83だと思います（@chrisfosterelliが間違っている場合は訂正してください）。これらの変数（UID、GIDなど）は動的であり、次のように設定する必要があることが明らかになりました。ランタイム（特に内部およびマウントされたボリュームから所有されているファイルへの書き込み）ですが、現在それを行う方法がありません。 これまでのところ、応答は実行時に決定されるべきではないようですが、それはそのような提案によって提示された基本的なユーザビリティの問題を無視しています。 繰り返しますが、私がこれのいずれかを誤解している場合は、遠慮なく私を訂正してください。

@jakirkhamユーザビリティの問題が何であるかを理解してはいけません。
ファイルはイメージ内にあり、アプリケーションの実行に必要な所有権と権限を持っている必要があります。 ボリューム自体とは何の関係もありません。 ボリュームは、画像に設定されたものをそのまま使用します。

@ cpuguy83もう少し掘り下げて、これに分離しました。起動時にディレクトリ/dataを作成するelasticsearchコンテナーがあるとします（データが存在しない場合）。次に、 docker run -v /data elasticsearchを使用します。 。 ディレクトリ/dataはroot:rootによって所有され、コンテナ内でelasticsearchとして実行されるデーモンは、 /dataに書き込めないため、起動に失敗します。

カスタムDockerfileを必要とせずにこのボリュームをelasticsearchが所有するように設定できれば理想的ですが、この種の問題はアップストリームイメージで解決する必要があると主張できると思います。

@chrisfosterelliカーネルメーリングリストには、所有権を変更できるドライバーのようなオーバーレイがあるという話がありますが、そのようなものなしでできることはあまりありません。 私は興味があります。ボリュームワールド内のすべてのファイルを適切に読み取りおよび書き込みしてumaskを設定し、新しいファイルも適切に設定できるでしょうか。 （私はまだ試していません）。

@justincormack私はそう信じていますが、コンテナが（ホストではなく）ボリュームにデータを作成することを期待している場合は機能しないと思います。 これは一種の奇妙な問題であることを理解しているので、現在、アップストリームのDockerfile自体でディレクトリのmkdir -p && chmodに修正することで対処しています。

@chrisfosterelliが、umaskを設定すると言った理由です。umaskが000 （コンテナー内）の場合、すべての新しいファイルは666または777のアクセス許可で作成されます。マウントポイントは777から始めても大丈夫ですか？ パーミッションが常にワールド読み取りおよび書き込みである場合、uidとgidは重要ではありませんか？

@justincormackはい、それは正しいように聞こえます...ホストにマウントされていないボリュームでDockerコンテナを作成しているときに、どうすればそれを行うことができますか？

@chrisfosterelliうーん、それは良い質問です。 新しいボリュームのパーミッションはデフォルトのumaskが与えるもののように見えるので、 000 umaskを使用してdockerデーモンを実行し、ボリュームが誰でも書き込み可能かどうかを確認できます。 たぶん、 docker volume createにいくつかの権限オプションがあるはずです。

（ chmodを実行して終了したルートコンテナで修正することもできますが、それは醜いです）

作成時に良くありません。 問題は、コンテナにパスがない場合、パスがルートで作成されることです。 これは、渡されたユーザーが何であれ、ほぼ間違いなく実行できます。

@ cpuguy83ユーザーが-uを渡して渡したときに作成する方が理にかなっていると思います。これは、おそらくユーザーがコンテナー内からボリュームを書き込もうとしているためです。

以下の手順を使用して、選択したユーザーとしてマウントできました。

• ホスト上のファイルを所有しているユーザーと同じUID / GIDを使用してDocker内にユーザーを作成します。
• 事前にマウントポイントを作成し、コンテナ内のターゲットユーザーにそれらをchownします

引用@chrisfosterelli ：

もう少し掘り下げて、これに分離しました。起動時にディレクトリ/ dataを作成するelasticsearchコンテナーがあるとします（データが存在しない場合）。次に、docker run -v / dataelasticsearchを使用します。 ディレクトリ/ dataはroot：rootによって所有されるようになり、コンテナ内でelasticsearchとして実行されるデーモンは、/ dataに書き込めないため、起動に失敗します。

これは素晴らしい例です！ Solr画像でも同様の例があります。 Solrには1つ以上の「コア」が必要です。各コアは、関連する構成ファイルと索引フラグメントのコレクションです。 各コアは、ユーザー指定の名前でディレクトリ内に配置されます。 たとえば、 productsという名前のコアを作成する場合、パスは/opt/solr/server/solr/productsになります。 コアの名前は私が選択したため、Solrイメージメンテナーはイメージ内にこのディレクトリを事前に作成できません。

すべてのドキュメントのインデックスを再作成せずにイメージを新しいSolrにアップグレードできるように、インデックスデータを保存したいのですが、ボリュームを/opt/solr/server/solr/productsにマウントすると、そのボリュームはrootによって所有されます。 solrとして実行）は実際には何も書き込むことができません。 親ディレクトリ/opt/solr/server/solrには他のファイルが含まれているため、そこにもボリュームをマウントできません。 （最新のDocker用語では、私のボリュームは「名前付きボリューム」と呼ばれていると思います。つまり、ホスト上の指定されたパスにマウントされていないが、Dockerによって完全に管理されているボリュームです。）

私はこれについてSolrイメージメンテナーと話しましたが、いくつかの回避策があります（そして、彼は役立つようにイメージにいくつかの変更を加えました）が、それはすべてかなりハッキーであり、アップストリームイメージにケースバイケースで変更する必要があります。 このスレッドで説明されている機能があると、新しいDockerfileを作成しなくても、_すべてのイメージ_がより拡張可能になります。

@ctindel多分...ディレクトリがまだ存在しない場合。

@ cpuguy83そうですね、同意します。 それは間違いなく私のユースケースでした。 コンテナを実行するためにユーザーIDが明示的に指定されている場合にディレクトリが存在しない場合、ディレクトリをrootとして作成することは意味がないようです。

@ cpuguy83名前付きボリュームでのみ機能します。

@kamechen何がうまくいくの？

@ cpuguy83名前付きボリュームを使用する場合、ファイルは必要なユーザーの下にマウントされます

@eciucaまあ....それは異なります。 名前付きボリュームが空の場合、または名前付きボリュームのデータがたまたま必要だったのと同じユーザーによって作成された場合。

@andrewmichaelsmithによって提起された問題の解決策はありましたか？

これで解決できる問題に直面しています（私は思います）。 開発者のホームディレクトリ用にNFS共有があります。 開発者は/ home / dev / git / projectをDockerにマウントしたいのですが、ルートスカッシュが有効になっているためできません。

これにより、rootが/ home / dev / git / projectにアクセスできなくなるため、docker Mounting / home / dev / git / projectを実行しようとすると、lstatパーミッション拒否エラーが発生します。

bindfsを使用してこれを回避することは可能だと思います。
dockerの-v ...を使用してボリュームを一時的な場所にマウントし、次にbindfsを使用して別のユーザーとして必要な場所にマウントします。

@piccaso 、私が@andrewmichaelsmithを理解した方法は、問題は、rootsquashが原因でホスト側のバインドマウントが失敗することであるということです。 ただし、bindfsは実際には回避策として使用できますが、今回はホスト側で使用します。 まず、ホストで、FUSEを使用してnfs共有を非rootユーザーとして一時的な場所にバインドマウントし、次にその一時フォルダーを-v ...を使用してDockerにマウントします。

bindfs（少なくともFUSEでは）にはかなりのCPUオーバーヘッドがあることに注意してください。

はい、bindfsは非常に望ましくありません。 CoWファイルシステムよりも低速です。
カーネルで行われているいくつかの作業により、マウントでuid / gidをシフトできるようになります。

カーネルで行われているいくつかの作業により、マウントでuid / gidをシフトできるようになります。

これはおそらく、コンテナ内のuid / gidを再マップしたいユースケースに対処するのに役立つだけです。 dockerデーモンによって実行されるマウント自体は、ホスト上でrootとして実行されます。 私の理解では、カーネルバインドマウントではrootとしてのみ作成できます。 root以外のユーザーがマウントを実行できるようにするためにそれを変更する作業があるかどうかはわかりません（Linuxがマウントを処理して意味があるかどうかを判断する方法についてはほとんど知りません）。

@NikolausDemmelそれが変わるとは思えません。 mount syscallにはCAP_SYS_ADMINが必要です。これは、root以外のユーザーに与えられるものではなく、コンテナーのrootユーザーに与えられるものでもありません。

@ cpuguy83説明してくれてありがとう。 つまり、ルートスカッシュを使用したNFSマウントであるホストフォルダーへのDockerボリュームのマウントは、（あなたが言うようにマウントsyscallの制限のために）予見可能な将来には機能しません。ただし、 bindfsでFUSEなどの回避策を使用する場合を除きます。

申し訳ありませんが、OPがコンテナ内のUID / GIDの変更について質問していたため、これは少しOTでした。 しかし、それはコインの裏側のようなものであり、上記の議論で浮かび上がってきました。 その違いを明確にしたかっただけです。

Docker for Macを実行していて、ボリュームをマウントしましたが、ファイルにアクセスするためのWebサービスに設定されたアクセス許可を取得できないようです。 これをどのように修正しますか？ パーマを変えてグループをスタッフに設定してみましたが、アルパインにはスタッフグループがないようです。

申し訳ありませんが、これが最適な場所ではない場合、私は何日も苦労していて、これ以上の場所を考えることができませんでした。

@NikolausDemmel ：いくつかのバイオインフォマティクス作業にDockerを使用しようとしています。 NFSを介してルートスカッシュされた複数の巨大なファイルシステムがマウントされています。 巨大な配列データ（fastq）を読み込み、ゲノム読み取りをデータストアに合わせて、やや小さいBAMファイルを書き出します。 現在、カスタムイメージを実行してコンテナ内にユーザーを作成し、最後にUSERを使用して機能させることで、Dockerを使用できますが、これにはいくつかの理由で問題があります。

1. 他の人のDockerイメージを使用する場合は、カスタムDockerfileを使用して再構築する必要があります
2. ローカルユーザーごとにカスタムDockerイメージを作成する必要があるか、単一の「サービス」アカウントを使用すると、FSでのユーザーのアクティビティを区別できなくなります。

BindfsまたはuserNSでこれを回避できますか？

私は同じ問題に直面していると思います、私のユースケースは次のとおりです：
Dockerイメージは、特定のプロジェクトのポータブルビルドツールを保持しますdocker run -v ./:/src/ imageなどの相対パスまたはdocker-composeファイルの同等のパスを使用したボリュームマウントを使用します。 ビルドが自動的に開始され、リンクされたボリュームのサブフォルダーに新しいファイルが生成されます。
ホストからビルドされたファイルを使用したい場合もありますが、dockerを実行したホストユーザーではなく、dockerのユーザーがそれらを所有しているという事実は、物事を難しくする傾向があります。

私はここで特に間違ったことをしていますか？

@rlabrecqueは、DockerユーザーのIDとホストのIDの照合について、以前の私の投稿を参照してください。 私はこのアプローチを使用しました、そしてそれは私たちにとって本当にうまくいきます。 基本的に、 HOST_UID=$(id -u)とHOST_GID=$(id -g)を実行し、以下の2つのコマンドで$ HOST_GIDと$ HOST_UIDを展開するDockerfileを生成します。

RUN groupadd -g $HOST_GID mygroup
RUN useradd -l -u $HOST_UID -g mygroup myuser

IDを入力して生成されたDockerfileを使用して、イメージを構築します。

@haridsv私は似たようなことをしましたが、Linuxでうまく機能します。 しかし、それはWindowsではうまくいかないようです。マウント内のファイルはまだrootによって所有されています。

私はinotifywaitを使用してこれを解決しました。 Dockerイメージ内で実行するには、inotify-toolsをインストールする必要があります。 代わりにホストシステムで実行することも可能ですが、ポータブルなソリューションが必要でした。

RUN export DEBIAN_FRONTEND=noninteractive \
  && apt -y update \
  && apt -y install inotify-tools \
  && inotifywait -m -r /mount -e create --format '%w%f' \
    | while read f; do chown $(stat -c '%u' /mount):$(stat -c '%g' /mount) $f; done

これは、ディレクトリ/ mountに作成された新しいファイルまたはディレクトリを監視するようにinotifywaitに指示することで機能します。 1つに気付くと、所有権が/ mountフォルダーと同じユーザーおよびグループに変更されます。 ホストユーザー/グループがコンテナーに存在しない場合に備えて、両方の整数表現を使用しました。 コンテナ内では、すべてがrootとして実行されるため、誰がコンテナを所有するかは関係ありません。 コンテナの外部では、ホストファイルシステムは/ mountにマウントされたディレクトリと同じ所有権を示します。

既存のファイルとディレクトリの所有権を保持するために、新しく作成されたファイルとディレクトリの所有権のみを設定するように意図的に設計しました。 ファイルシステムがマウントされるたびに、chown-Rステートメントですべてを吹き飛ばすよりも安全です。 プロジェクトで統一された権限が機能し、より効率的に実行されるより単純なソリューションが必要な場合は、 inotify-hookableを確認してください。

警告：サブディレクトリごとに1つのinotifyウォッチが確立されるため、ユーザーごとのinotifyウォッチの最大数に達する可能性があります。 デフォルトの最大値は8192です。 / proc / sys / fs / inotify / max_user_watchesに書き込むことで増やすことができます。

ホスト側スクリプトを使用して、マウントされたボリュームbengをchownしました。これにより、イメージを再構築する必要がなくなります。

#!/bin/bash
set -e

DOCKER_IMAGE=<docker_image>
COMMAND=<internal_command>

DOCKER_USER=docker-user
DOCKER_GROUP=docker-group

HOME_DIR=/work
WORK_DIR="$HOME_DIR/$(basename $PWD)"

PARAMS="$PARAMS -it --rm"
PARAMS="$PARAMS -v $PWD:$WORK_DIR"
PARAMS="$PARAMS -w $WORK_DIR"

USER_ID=$(id -u)
GROUP_ID=$(id -g)

run_docker()
{
  echo \
    groupadd -f -g $GROUP_ID $DOCKER_GROUP '&&' \
    useradd -u $USER_ID -g $DOCKER_GROUP $DOCKER_USER '&&' \
    chown $DOCKER_USER:$DOCKER_GROUP $WORK_DIR '&&' \
    sudo -u $DOCKER_USER HOME=$HOME_DIR $COMMAND
}

if [ -z "$DOCKER_HOST" ]; then
    docker run $PARAMS $DOCKER_IMAGE "$(run_docker) $*"
else
    docker run $PARAMS $DOCKER_IMAGE $COMMAND "$*"
fi

ホストディレクトリでファイルシステムACLを使用するのはどうですか？ このようにして、ディレクトリ内に新しく作成されたファイルに特定のアクセス許可を適用するようにファイルシステムに指示できます。 ACLをホストレベルで設定した場合、コンテナからのデータを変更すると、それも発生します。

@thaJeztah @justincormack @ cpuguy83

@kamechenは、指定されたボリュームが「正しく機能する」というのは正しいようです。 名前付きボリュームの場合、既存のアクセス許可が「バックファイア」してボリュームのアクセス許可を変更します。個人的には、これをバグと見なします（＃28041）。

@thegecko 、なぜこのアプローチをさらに進めて、エントリポイント内にユーザーを作成しないのですか？

これが私の例です。マウントされたディレクトリの所有者を検出し、同じUIDを持つユーザーを作成し、このユーザーの下でコマンドを実行します。

Dockerfile

FROM ubuntu

RUN mkdir /project
VOLUME /project

ENV GOSU_VERSION 1.9
RUN set -x \
    && apt-get update && apt-get install -y --no-install-recommends ca-certificates wget && rm -rf /var/lib/apt/lists/* \
    && dpkgArch="$(dpkg --print-architecture | awk -F- '{ print $NF }')" \
    && wget -O /usr/local/bin/gosu "https://github.com/tianon/gosu/releases/download/$GOSU_VERSION/gosu-$dpkgArch" \
    && wget -O /usr/local/bin/gosu.asc "https://github.com/tianon/gosu/releases/download/$GOSU_VERSION/gosu-$dpkgArch.asc" \
    && export GNUPGHOME="$(mktemp -d)" \
    && gpg --keyserver ha.pool.sks-keyservers.net --recv-keys B42F6819007F00F88E364FD4036A9C25BF357DD4 \
    && gpg --batch --verify /usr/local/bin/gosu.asc /usr/local/bin/gosu \
    && rm -r "$GNUPGHOME" /usr/local/bin/gosu.asc \
    && chmod +x /usr/local/bin/gosu \
    && gosu nobody true \
    && apt-get purge -y --auto-remove ca-certificates wget

ADD entrypoint.sh /

ENTRYPOINT ["/entrypoint.sh"]

CMD /project/run.sh

entrypoint.sh

#!/bin/sh

USER=dockeruser
VOLUME=/project
UID="$(stat -c '%u' $VOLUME)" && \
useradd --uid "$UID" "$USER" && \
ls -l "$VOLUME" && \
exec gosu "$USER" "$@"

run.sh

#!/bin/sh

echo "Running as \"$(id -nu)\""

sudo docker build -t test . && sudo docker run --rm -v /tmp/docker-test/:/project test:latestを実行すると、次のように出力されます。

total 12
-rw-r--r-- 1 dockeruser dockeruser 990 Dec 12 10:55 Dockerfile
-rwxr-xr-x 1 dockeruser dockeruser 156 Dec 12 11:03 entrypoint.sh
-rwxr-xr-x 1 dockeruser dockeruser  31 Dec 12 11:01 run.sh
Running as "dockeruser"

誰かがこの問題を検討しましたか？ ボリュームのgidとuidがコンテナーと同じであることを確認すると、rootを使用しないようにコンテナーを管理することが難しくなります。 Dockerのベストプラクティスでは、可能であればrootでサービスを実行しないことを推奨していますが、ホスト上でgidとuidをセットアップする必要はなく、コンテナーはDockerの人気を高めた使いやすさを損なうようなものではありませんか？

@AndreasBackxボリュームの使用は、マウント先のパスにデータが含まれていることを前提として機能します。
バインドを使用すると、ホストパスのUID / GIDが使用されます。

ひどく遅いFUSEのようなものを使用しない限り、現在、元のファイル/ディレクトリを変更せずにファイル/ディレクトリのUID / GIDを他の何かにマップまたは変更する方法はありません（カーネルサポートがない場合など）。

しかし、少し前に戻りましょう。
Dockerは、ここで物事を実際に難しくしているわけではありません。
コンテナ内のUID / GIDは、ホスト上のUID / GIDと同じです。ユーザー/グループ名が一致しない場合でも、ここで重要なのはUID / GIDです。
Dockerがない場合と同じように、サービスに使用するuid / gidを考え出し、慣例に反して使用する必要があります。
ファイルの所有権を設定するために、uid / gidが/etc/passwdまたは/etc/groupに存在する必要はないことを忘れないでください。

@ cpuguy83説明ありがとうございます。

今日、 nodeパイプラインを作成しているときにこの問題が発生しました。ホストユーザーのUIDは1000で、 nodeイメージはその特定のUIDを持つカスタムユーザーを作成します。それについても問題があります。

ノードユーザーを使用して先に進みますが、少し汚れているように感じます。 @ cpuguy83に書いた「少し後退しましょう」については本当に共有していますが、問題を解決するのが難しい場合があります。

重複したIDSを許可するためにusermodの-oオプションを見つけたところ、正当なオプションのようです。

RUN usermod -o -u 1000 <user>

なぜこれが合理的な方法で修正されていないのかわからない。

docker run -it -u 1000:4211 -v /home/web/production/nginx_socks:/app/socks -e SOCKS_PATH=/app/socks --name time_master  time_master

ログインして確認してください。

drwxr-xr-x    8 geodocr_ geodocr       4096 Jun  4 18:51 .
drwxr-xr-x   57 root     root          4096 Jun  6 21:17 ..
-rwxrwx---    1 geodocr_ geodocr        140 Jun  4 18:49 .env
-rwxrwx--x    1 geodocr_ geodocr         78 Jun  4 18:49 entrypoint.sh
drwxrwxr-x    2 geodocr_ geodocr       4096 Jun  4 18:51 handlers
-rwxrwx---    1 geodocr_ geodocr        242 Jun  4 18:49 requirements.txt
-rwxrwx---    1 geodocr_ geodocr       1270 Jun  4 18:49 server.py
drwxr-xr-x    2 root     root          4096 Jun  6 21:00 socks
drwxr-xr-x   10 geodocr_ geodocr       4096 Jun  4 18:51 utils

dockefileは特に

RUN adduser  -D -u 1000 $USER 
#
RUN addgroup $GROUP -g 4211 
#
RUN addgroup $USER $GROUP 
RUN mkdir /app/socks
USER $USER  
#

コンテナ内のユーザーが選択されていない場合、またはコマンドを実行しているユーザーが選択されていない場合、このボリュームがrootとしてマウントされても意味がありません。 RUNコマンドが、コマンドを実行しているユーザーとしてマウントされているのか、ディレクトリを所有しているユーザーとしてマウントされているのか、Dockerfileで指定されているユーザーとしてマウントされているのかがわかりました。

これらはいずれもrootではないため、rootとしてマウントするのはバグのようです。

また、チェックしてボリュームを作成し、マウントすると機能します。 だからまだバグ。

@disarticulateホストパスをroot以外にする場合は、ホストパスを変更する必要があります。

これについては以前に言及されていないと思いますが、Dockerを使用してホストボリュームを作成する場合、このバグは特に厄介です。 マウントしているディレクトリの所有者が異なる場合でも、Dockerは常にrootを使用してホストボリュームを作成しているようです。

ここで行う正しいことは、イメージのUSERに属する所有権権限を持つボリュームを作成することであるように思われます。

@jalazizコンテナのユーザーがホストに存在しない場合はどうすればよいですか？ コンテナーの主な利点の1つは、コンテナーの依存関係（ユーザーを含む）をホストに公開する必要がないことです。

@taybin Dockerは、コンテナーのユーザーのuid：gidを使用してフォルダーを作成するか、フォルダーがコンテナー内に存在する場合は、同じuid：gidとマスクを使用してホストフォルダーを作成することを期待します。

注：フォルダーがホストに既に存在する場合、Dockerの変更権限は期待していません。

@ taybin @ frolが説明したとおりです。 コンテナのuid：gidを使用する必要があります。

ただし、これにより、現在のアプローチに関する私の一般的な問題が明らかになります。 コンテナが書き込みを許可し、そのuid：gidに基づいてホストディレクトリへのアクセス許可を設定するために使用するuidを知る必要があります。 アップストリームの作成者がuidを変更すると、権限が失われます。 それはすべて非常に壊れやすいようです。

私の場合、使用されているDockerイメージを明示的に制御する必要はありませんでした（Dockerfileを好みに合わせて編集することはできませんでした）。

だから、私はこれを試しました：

docker run -it -u $(id -u $USER):$(id -g $USER) -v $(pwd):/src -w /src node:latest npm run build

これにより、 ./built-appというフォルダが作成されます。 ただし、所有者は依然としてrootであり、厳格な権限があります。

私の回避策はこれでした：

docker run -it -v $(pwd):/src -w /src node:latest /bin/bash -c "npm run build; chmod -R 777 ./built-app"

これにはまだrootの所有者がいますが、権限は緩和されています。 その後、私のホストOS（Ubuntu）はsudo権限なし./built-appにアクセスできました。

@ rms1000watt次のコマンドを試しましたか？

docker run -it -v $(pwd):/src -w /src node:latest /bin/bash -c "npm run build; chown -R ${UID}:${GID} ./built-app"

ホストのUIDとGIDをファイル自体に直接使用するため、これは機能するはずです。 chmod -R 777を使用することは、一般的に悪い習慣です。

@saadaおっと！ よろしくお願いします。 試してみます。

これを読んで、_ UIDとGIDがDockerコンテナでどのように機能するかを理解することで、私のアプローチを達成できました_
https://medium.com/@mccode/understanding -how-uid-and-gid-work-in-docker-containers-c37a01d01cf

基本的に、単一のカーネルと単一の共有uidおよびgidのプールがあります。これは、ローカルマシンのルートがコンテナのルートと同じであり、両方が同じUIDを共有することを意味します。

私はApacheサーバーを持っており、WebアプリケーションファイルをApacheコンテナーと共有して、ホスト上で変更し（開発、テキストエディターを使用して変更）、コンテナーで実行されているプロセスによる結果を確認したいと考えています。 そのプロセスで、新しいファイルを作成することがあります。デフォルトの動作を変更しない場合、ファイルはrootユーザーによって生成され、ローカルユーザーはそれらを変更できなくなります。

私がしたことは、これをdockerfileに追加してカスタムイメージを生成することでした。

RUN adduser -D -u 1002 dianjuar -G www-data
USER dianjuar

たぶん、私のdocker-compose.ymlを誰にでも移植できるようにするために、ビルドプロセスにいくつかのパラメーターを設定します。

これは、実行時にユーザーID /グループIDを簡単に移植できる方法で割り当てるためのコンテナーパターンです。 https://github.com/Graham42/mapped-uid-docker

私が従った方法：

1-ホストサーバーにディレクトリを作成します
2-useridおよびgroupid = 1000を持つユーザーへのアクセス許可を変更します
3- docker-compose upを実行します
コンテナをチェックし、すべてが正常です。

注：ホストサーバーでrootユーザーを使用しており、uid = 1000のroot以外のユーザーを使用している場合、権限を気にせずにボリュームをマウントできると思いますが、まだテストしていません。 同様の方法に従った人はいますか？

典型的な問題：

• docker swarm、CAPP_ADDは使用できないため、bind-mountは解決策ではありません
• 2つの異なるイメージの2つのコンテナは同じボリュームを共有するため、両方の異なるユーザー/グループデータベース
• たとえば、アクセス権www-dataが必要です（つまり、証明書ダウンローダーを暗号化しましょう）
• もう1つもwww-data（つまりnginx）を使用します
• ただし、3つ目は、ユーザーopenldap（つまり、openldapサーバー）からのアクセスが必要です。
• とても単純なchmodも解決策ではありません

つまり、encrptからドメインのSSL証明書を取得するWebサーバーと、証明書を再利用したい同じドメインのOpenLDAPサーバーがあります。

まったく同じ問題が発生する他の組み合わせがあります。

任意のアイデア、これを解決する方法は？

Dockerなしでこれをどのように解決しますか？ これはDocker固有ではありません
問題。

2018年1月12日金曜日午前10時24分、 MarcWäckerlinnotifications @ github.com
書きました：

典型的な問題：

• docker swarmであるため、CAPP_ADDは使用できず、bind-mountは使用できません
  解決
• 2つの異なる画像の2つのコンテナは同じボリュームを共有するため、
  両方の異なるユーザー/グループデータベース
• たとえば、アクセス権www-dataが必要です（つまり、暗号化しましょう）
  証明書ダウンローダー）
• もう1つもwww-data（つまりnginx）を使用します
• しかし、3番目のものはユーザーopenldap（すなわちopenldap）からのアクセスを必要とします
  サーバ）
• とても単純なchmodも解決策ではありません

つまり、ドメインのSSL証明書を取得するWebサーバーがあります
私が望む同じドメインのencrptとOpenLDAPサーバーから
証明書を再利用します。

まったく同じ問題が発生する他の組み合わせがあります。

任意のアイデア、これを解決する方法は？

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/moby/moby/issues/2259#issuecomment-357267193 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAwxZgyvdCwGGVkUqCxK9nDFw1zxSKjUks5tJ3kXgaJpZM4BGxv9
。

-

• ブライアンゴフ

群れがなくても、docker：bind-mountで解決できました。

CAP_ADDがないため、これはDocker-Swarm固有の問題です。

@mwaeckerlinバインドマウントは、異なるユーザーIDにマップできません。
しかし、群れでもマウントをバインドできます....なぜCAP_ADDが必要なのですか？

CAP_ADDがないと、Docker内のマウントは失敗します。

しかし、コメントを書くことで、可能な解決策が得られましたが、残念ながら、両方の画像のDockerfileを変更する必要があるため、ライブラリやその他のサードパーティの画像では機能しません。

• すべてのDockerfileで明示的に指定された共通グループIDを使用してグループを作成します
• グループに権利を与える

@mwaeckerlinなぜコンテナ内にマウントする必要があるのですか？

Dockerオプション-vでユーザー/グループを指定できないため。

上記で指定されたアイデアは次のとおりです。コンテナ内にバインドマウントしてから、ターゲットにchownしてソースを変更しないでください。

@mwaeckerlin変更すると、どこでも変更されます。 これがこの問題の問題の核心です。
バインドマウントされたファイル/ディレクトリをChowning / Chmodingすると、両方の場所が変更されます。

また、コンテナ内にマウントできる必要はありません--mount type=bind,source=/foo,target=/bar

はい、Dockerの外でテストしたばかりなので、上記の考え方は間違っています。

Dockerでよく見られる主な問題は、ユーザー、グループが異なるイメージで同一ではないことです。両方に同じユーザー名またはグループ名が存在する場合でも、IDが異なることがよくあります。

ここでは、このようなものが少なくとも場合によっては役立ちます： --mount type=bind,source=/foo,target=/bar,user=me,group=mine

このトピックに関する推奨事項またはベストプラクティス：docker swarmのさまざまなイメージのさまざまなユーザーによる共有ボリュームユーザー？

1. ボリュームを共有しないでください
2. uid / gidsを同期します
3. 共有しているすべてのユーザーに対して十分な権限が許可されていることを確認します
4. ホストのヒューズマウントを使用して、コンテナごとに異なるuid / gidにバインドします

ポイント4について詳しく教えてください。
おそらくそうする方法についての実際的な例？

2018年1月12日金曜日、17：27 Brian Goff、 notifications @ github.comは次のように書いています。

>>

1. ボリュームを共有しないでください
2. uid / gidsを同期します
3. 共有しているすべてのユーザーに対して十分な権限が許可されていることを確認します
4. ホストのヒューズマウントを使用して、それぞれの異なるuid / gidにバインドします
   容器

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/moby/moby/issues/2259#issuecomment-357282169 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AHSjvgjb0BFbJhZ1VWM-pLGfa7tRBvDNks5tJ4VPgaJpZM4BGxv9
。

https://bindfs.org/のようなものを使用します-すでにそれを実装しているDockerボリュームプラグインが少なくとも1つあります（https://github.com/lebokus/docker-volume-bindfsはGoogleで最初に見つけた結果です） 。

ボリュームをマウントした後に権限を変更できませんが、誰かがこれを取得しますか？

回避策：
これをDockerfileに追加する
RUN echo "if [ -e container_volume_path ]; then sudo chown user_name container_volume_path; fi" >> /home/user_name/.bashrc
ボリュームがマウントされた後、 container_volume_pathの所有権が変更されます。

uidとgidをマッピングできることは、Dockerボリューム処理に不思議な欠落要素のように見えます。 驚き最小の原則はそれを含めることであり、提案された修正は不格好で発見が困難ですが、ベストプラクティスの利点はありません。

再：
1）ボリュームを共有しないでください

• 良いですが、uid / gidのマッピングに関する議論には重要ではありません
  2）uid / gidsを同期します
• これが機能の目的ですが、Dockerfileでchownを強制することはありません
  3）権限が共有しているすべてのものに対して十分に寛容であることを確認します
• これも、単純なマッピングである可能性がある場合、Dockerfileで定義された動作に依存します
  4）ホストのヒューズマウントを使用して、コンテナごとに異なるuid / gidをバインドします
• 良いアドバイス、それもヤクを剃っているようです。

@colbygk

単純なマッピングである可能性がある場合

これが問題です。vfsレイヤーではサポートされていないため、「単純なマッピング」を実行することはできません。
一部のファイルシステム（bindfsやnfsなど）は所有権をマップする機能を提供しますが、一般的なケースでこれを実装することは現在不可能です。

共有ボリュームが必要です。たとえば、次のような状況です。

共有証明書

• コンテナ1は、ホストされているすべてのドメインの暗号化を処理するリバースプロキシです。
• コンテナ2はLDAPサーバーであり、そのドメインの証明書も提供する必要があります

解決策：イメージコンテナ2はコンテナ1と同じイメージを継承し、共通のベースイメージは共通のグループを作成し、両方のコンテナが同じグループアクセスを持ちます

共通ベースのDockerfile ：

RUN groupadd -g 500 ssl-cert

画像を暗号化してみましょう： letsencrypt-config.sh ：

chgrp -R ssl-cert /etc/letsencrypt

mwaeckerlin / reverse-proxyのDockerfile ：

RUN usermod -a -G ssl-cert www-data

mwaeckerlin / openldapのDockerfile ：

RUN usermod -a -G ssl-cert openldap

それでおしまい。

これらはすべて、エントリポイントまたはビルドプロセス中にuserpermsを変更して、Docker全体を別のユーザーで実行する方法を示しています。

しかし、過去3日間ウェブを検索した後、大きなポイントを見逃しているかもしれません。
上記またはその他の方法でリンクされた推奨事項および（回避策）は、いずれの方法でも機能しません。

コンテナにマウントされたすべてのボリュームは、常にコンテナ内のroot：rootによって所有されます。 UID / GIDが一致するホストの所有者を事前に変更するかどうかは関係ありません。

私の観点からすると、非常に基本的なことをしようとして愚かであるという感覚を失うことはできません。

• Windows 10 Pro 1803（17134.112）
• Docker for Windows 18.03.1-ce-win65（17513）
• Hyper-VおよびUbuntuを搭載したWindowsWSL

ドキュメントルートがホストにマウントされているプレーンなapache2コンテナーを起動しようとしているので、dockerコンテナーですぐにテストしながらphpソースコードで開発できます。

root<strong i="16">@win10</strong>:# docker run --rm -v /c/Users/<MyUser>/Development/www-data:/var/www/html -it httpd:2.4 /bin/bash

Dockerコンテナ内では、directoy _ / var / www / html_は常に_root ：root_によって所有されているため、私のphpアプリはfopenしたり、そのフォルダー内のデータを書き込んだりすることはできません。
まだ何も機能していません... :(

適度にエレガントな解決策を探している人は、 @ elquimistaがここで提案したものをチェックしてください。 私はこれをテストし、うまく機能しています

運が良ければhttps://github.com/boxboat/fixuid#specify-paths-and-behavior-across-devicesを使用しています。 さらに、ホスト上のユーザーと一致するようにコンテナー内にユーザーを設定します。

画像の構成例を次に示します。

$ cat /etc/fixuid/config.yml
user: lion
group: lion
paths:
  - /home/lion
  - /home/lion/.composer/cache
  - /tmp

実行するには：

$ docker run --rm -it --init \
    -u 1000:1000 \
    -v `pwd`:/app \
    -v "$HOME/.composer/cache:/home/lion/.composer/cache" \
    --entrypoint='fixuid' \
    php:7.2-cli \
        /bin/bash

これは、UNIXのアクセス許可と所有権をサポートしていないストレージシステムを使用する場合にも厄介であることに注意してください。 その場合、ストレージのマウントは、ファイルをchownしようとすると失敗するため、コンテナー内で使用するための正しいuidを取得するように実行する必要があります。 コンテナの外部の所有権に関係なく、特定のuidによって所有されているものとしてファイルを提示するようにdockerに指示する方法があれば、物事が単純化されます。

@tlhonmey

特定のuidが所有するファイルを提示するようにdockerに指示する方法があった場合

カスタムファイルシステム（bindfsなど）がないわけではありません。

@tlhonmeyええ、私はいくつかのシンボリックリンクで「UNIXパーミッションをサポートしないストレージシステム」の問題を回避することができました。

基本的に、NTFSドライブからマウントする場合は、 -v ./HostNtfsStuff:/data/ntfsMountに入れてから、シンボリックリンクを作成し、そのln -s -T /data/ntfsMount /var/lib/myApp && chown -Rh myApp:myApp /var/lib/myApp/をchownします。

あなたもテストすることができます： su myApp -c 'echo foo > /var/lib/myApp/bar' && cat /data/ntfsMount/bar

私が使用したのは、Windows開発者がMySQLコンテナーを実行し、マウントされたボリュームに永続化できるようにすることでしたが、多くのアプリに適用されます。

したがって、解決策は、一連のuid：gidペアを手動で管理し、それらがホストまたはヘルパースクリプトで衝突しないことを期待することです。または、次のようにします。

それを機能させる方法は1つありますが、Dockrfile内で事前に準備する必要があります。

RUN mkdir -p /var/lib/redis ; chown -R redis:redis /var/lib/redis
VOLUME ["/var/lib/redis"]
ENTRYPOINT ["usr/bin/redis-server"]
USER redis

（私はこの例をテストしませんでした。クロムコンテナで作業していて、それが_separate_X11コンテナに表示されます....）

コンテナボリュームをバインドマウントしようとしたときに壊れた今日まで、最後の手法を使用していました。 どうやらあなたはそれを行うことはできません。 ボリュームはrootとして作成され、内部のアプリはユーザーとしてボリュームに書き込むことができません。 VOLUMEドキュメントで説明されている自動入力は、バインドマウントでも機能しないようです。

私はこれがDockerfileのベストプラクティスを読んでいるのを見ました。ヘルパースクリプトは彼らが推奨するものです。

#!/usr/bin/env bash
set -e

if [ "$1" = 'postgres' ]; then
    chown -R postgres "$PGDATA"

    if [ -z "$(ls -A "$PGDATA")" ]; then
        gosu postgres initdb
    fi

    exec gosu postgres "$@"
fi

exec "$@"

したがって、再帰的なchownを使用して、すべての起動時に所有権があることを確認してから、ユーザーとしてアプリを実行します。 execもPID 1を強制するため、信号が機能します。 また、結果のデータでコンテナの外部で使用するヘルパースクリプトのようなものをボリュームに追加する場合は、おそらくヘルパースクリプトにも含める必要があります。 ただし、アプリがボリュームに大量のファイルを保存している場合、特にストレージがローカルでない場合、コンテナの起動にパフォーマンスの影響があるかどうか疑問に思います。

より良い解決策があるようです。 コンテナのuidとgidを、ホスト上の指定されたユーザー名とグループのものにマッピングするようなものかもしれません。 Dockerはコンテナの/ etcを覗いて、これを理解できるでしょうか？

少なくともヒューズなしでは、ファイルシステムレベルでuid / gidsをマップすることはできません。

少なくともヒューズなしでは、ファイルシステムレベルでuid / gidsをマップすることはできません。

ちょっと怖かったです。 Dockerがこのようなヒューズを使用した場合のパフォーマンスの低下はどうなるでしょうか？

@mdegans

したがって、すべての開始時に所有権を持っていることを確認するための再帰的なchown、

開始するたびにchownを実行する必要はありません。 代わりに、データディレクトリの所有者を確認し、正しくない場合にのみ再帰的なchownを実行してください。 このような：

 [ $(stat -c %U "$PG_DATA") == "postgres" ] || chown -R postgres "$PG_DATA"

したがって、理想的には、これは最初の起動時にのみ発生します。

また、このようなエントリポイントスクリプトを使用してコンテナを実行する場合は、十分に注意してください。 ホームディレクトリをコンテナにマウントすると（たとえば）、すべてのファイルがpostgresに変換されます

優れたDockerイメージの設計では、ランタイムユーザーはrootではないため、 chownファイルを使用できません…！

優れたDockerイメージの設計では、ランタイムユーザーはrootではないため、ファイルをchownできません…！

正解ですが、 rootとの間の切り替えを停止するものはないはずです。これは、多くの場合必要になります...通常、必要になるまでrootとして何かを実行するべきではないのと同じように、ただし、そうする場合は、次の1つ以上を実行できます。

• sudo
• su
• USER root

によると： https ：//f1.holisticinfosecforwebdevelopers.com/chap03.html#vps -countermeasures-docker-the-default-user-is-root

私の謙虚な意見では、Dockerイメージのユーザーが、マウントされたボリュームの権限を正しく設定するかどうかを確認する必要があります。

これは、コンテナが登場する前に従来行っていたことと非常によく似ています。たとえば、nginxを実行したいときに、静的HTMLディレクトリが適切なユーザーによって所有されていることを確認する必要がありました。 nginx.confファイルを開く必要があることを知るために、ワーカーのユーザーを確認し、それに応じてアクセス許可を設定します。 実際、これはすべてnginxのドキュメントに記載されています。

これは単なるUnix権限の問題であり、ここでのDockerの新しいことは何もありません。 したがって、おそらくこの問題の解決策は、マウントされたボリュームの所有権がどうあるべきかについての各Dockerイメージのより良いドキュメントです。 ディレクトリが正しい所有権を持っていることを確認したnginx起動デーモンを思い出せません。正しく設定されていないと、単に失敗します。

ただし、これは事実です。これは、コンテナーの外部ではなく内部でユーザーが定義される可能性があるため、外観が異なる（実際はそうではない）ためです。 ただし、UIDの内部と外部は同等であるため、UID 2000のユーザーfoobarは、外部ではなくコンテナーの内部に存在する可能性がありますが、UID2000は外部のファイルとディレクトリに設定できます。 以前扱っていた人間にわかりやすい名前ではなく、UID / GIDの観点から考え方を変える必要があります。
また、2人の異なる作成者によって作成された2つのコンテナー間でボリュームを共有する必要がある場合は、事態がさら​​に困難になる可能性があります。 従来のUnixシステム（ユーザー、グループなど）を使用してアクセス許可を設定するだけでは、問題を解決できない可能性があります（一般的なUIDまたはGIDはありません）。 私はDockerを使用しているので、POSIXACLをより多く使用していることを認めます。 したがって、同じファイルに3人の異なるユーザー権限を割り当てることができます。 たとえば、rw権限を持つコンテナライター、r権限を持つコンテナリーダー、r権限を持つホストユーザー。

もう1つのオプション：共有ディレクトリにsetgidフラグを使用して、共通のGIDを適用できます。 ファイルマスクは、ACLを使用して適用できます。

Dockerコンテナーで何かを行う前に、以下を実行します。

`` `
umask 0000
`` ``

https://en.wikipedia.org/wiki/Umask

このスレッドに遅れて立ち寄って、この機能がどれほど役立つかを再確認してください。

正直なところ、私は約1年前からコンテナを展開してきましたが、これが至る所で深刻な問題になっていると思います。 ここで、このレベルでソリューションを提供することは、唯一の賢明な選択のように思われます。

現在のところ、かなりの数のDockerイメージがエントリポイントをrootとして実行し続けることを選択したため、アプリケーションプロセスを実行する前に、ディレクトリとファイルのアクセス許可をブートストラップして特権を削除することしかできません。

誰もがこの慣習に頼ることができるわけではないことに気付いたときに、本当の問題が現れます。 KubernetesやOpenShiftなどの一部の一般的なプラットフォームでは、これらの環境の一部は、特権コンテナーを許可しないように構成されている場合があります...セキュリティのため。 大規模な金融機関が、この種の制限なしに機密情報を処理するコンテナプラットフォームの採用をどのように検討するかは、頭の中でわかりません。

_entrypoint-as-root_プラクティスによって提起されたセキュリティ上の懸念により、多数のKubernetesヘルムチャートがinitContainersを提供し、アプリケーションコンテナが起動する前にchownおよびchmodボリュームを提供できるようになりました。 。 これは良い方法のように思えるかもしれませんが、私がこれを言うときは私を信じてください：そうではありません。

特にヘルムチャートには、アプリケーションランタイムから密かにリッピングする必要があるため、ハードコードされuidsとgidsが散らばっています。 その情報はコンテナ内に隠されており、展開中にすぐに利用できるわけではありません。

この問題を回避する方法はいくつかありますが、それは_物事を機能させるためのハック_として、展開構成全体を悩ませ続けています。 これによって影響を受ける展開の数は急速に増加しており、人々が頼っている手法は、コンテナーがテーブルにもたらす他のすべての利点とは反対です。

これをOCI仕様の一部として実装して、Dockerに依存する他のソリューションがこれを使用して、完全に自動化されたデプロイメントをエレガントに提供できるようにする方法があることを願っています。

したがって、問題は次のようになります。インターネット上の他のどこで共通のOCI仕様を開発し、この議論をどこで行うべきか。 これがこの機能をDockerに組み込むための最良の方法ではないと仮定します（最終的には、一般的に合意された標準の採用を将来に準拠させるための要件を通じて）。

問題がそれ自体で完全になくなるわけではなく、解決策にはいくつかの非常に基本的な種類の変更が必要です。

アプリケーションコンテナが起動する前にボリュームをchownおよびchmodできるinitContainers。 これは良い方法のように思えるかもしれませんが、私がこれを言うときは私を信じてください：そうではありません。

FWIW; この機能は、ファイルが複数の名前空間（「ホスト」に存在するファイル（以前）、または異なるユーザーとして実行されている複数のコンテナー間で共有される共通のファイルの場所）間で共有される状況でのみ必要になります。 ファイルがホスト上に事前に作成されている状況では、コンテナーと共有する前に、それらのファイルが正しい所有権とアクセス許可を持っていることを確認することで、これを軽減できます。 事実上、これは（たとえば）ホストでnginxを実行し、Webルート内のファイルに正しいアクセス許可があることを確認することと何ら変わりはありません。

別のユーザーとして実行されているコンテナー間で共有する場合は、同じuid （またはgid ）で両方のコンテナーを実行し、2つを実行する場合と同様に、正しいグループ権限を設定します。同じリソースにアクセスする必要があるコンテナ化されていないプロセス）。

これらの環境の一部は、特権コンテナを許可しないように構成されている場合があります...セキュリティのためです。 大規模な金融機関が、この種の制限なしに機密情報を処理するコンテナプラットフォームの採用をどのように検討するかは、頭の中でわかりません。

混乱を防ぐためだけに。 rootとして実行されているコンテナは、「特権」コンテナ（ --privilegedまたは--cap-addセットなどのオプション）と同じではありません。 特権（ --privileged ）コンテナーは非常に安全ではありませんが、 rootとして実行されているコンテナーは完全に含まれており、ブレークアウトできません。 バインドマウントされたファイル/ディレクトリを渡すと、そこに穴が開いてしまうため、バインドマウントとして渡すファイル/ディレクトリにアクセスできるようになります。

特にヘルムチャートには、アプリケーションランタイムから密かにリッピングする必要があるため、ハードコードされたuidとgidが散らばっています。 その情報はコンテナ内に隠されており、展開中にすぐに利用できるわけではありません。

疑問に思う：それらのuid / gidsが知られていない場合; UXはどのようになりますか？ （ホストuid / gidを（不明な）container-uid / gidにマップするために使用するマッピングuid / gidを提供する必要があるため？

したがって、問題は次のようになります。インターネット上の他のどこで共通のOCI仕様を開発し、この議論をどこで行うべきか。

（一見）OCI仕様の変更が必要だとは思いません。 これは、OCI仕様の範囲外で解決できます。 主な問題は、uid / gidをマップするメカニズムが現在カーネルにないことです（または存在します（ shiftfsなど）が、一般的には利用できません）

これは、責任の譲渡の古典的な五角形です/他の誰かがこの問題を解決できる、または解決する必要があります。 どちらかです：

• ユーザー
• Docker /コンテナ化プラットフォームの特定の実装
• OCI仕様
• カーネル
• ファイルシステム

問題はすでに効果的に述べられています。ユーザーにこれを行わせることは、不格好で安全性が低いということです。 ただし、ユーザーに画像ごとのハッキングを行わせることによるノックオン効果も重要です。

つまり、さまざまなユーザーの画像を簡単に相互運用したり、共有/混合して共同作業したりすることはできません。 だからそれはどちらかです：

• コミュニティの共有を壊します（かなりたくさん）。 異なるユーザーが同じグローバル名前空間プールから、個別に開発されたイメージのuidとgidを定義するため
• ユーザーに独自のアドホック標準を開発させ、他のユーザーが自分で選択した規則に従うことを期待します
• ユーザーにすべてにrootを使用するように強制します。 これは、特定の安全性が低いためです。 なぜなら、他の方法では持っていたであろう特権昇格保護の余分な層を取り除いているからです。 また、ユーザーは最初からコンテナ内にすでにroot入っているため、コンテナブレイクアウトの脆弱性を悪用しやすくなります。 同じコンテナ内で他のサービスを実行できることは言うまでもありません。これは、上昇する前に横向きに移動するもう1つの方法でもあります。

だからそれは貿易です。 上記は現在のトレードオフです。 上記の他のエンティティの1つ以上に責任を他の場所に移すには、さまざまなトレードオフが必要になります。

ところで、ファイルシステムベースのソリューションを詳しく調べることに関して、スパイダーリンクの「潜在的に役立つ可能性がある」コメントを見つけました。

https://github.com/docker/compose/issues/3270#issuecomment -365644540

これには、分散ファイルシステム（「Lustre」と呼ばれる）やZFSに関するその他の問題など、この同じ一般的な機能（他のプロジェクト/場所）へのいくつかの異なる参照があります。 ええと、私はたまたまここでZFSを使用しています。

次に、ubuntu / launchpadで同じバグの別のコピーを見つけました。 同じZOL＃4177の問題を参照して、

https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1567558

これは、問題のバグがzfsバージョン0.6.5.7 + SOで修正されたことを示しています。 これは、何らかの方法でuidとgidを再マッピングするためのある種のバッキングストアとして、zfsとACLを使用できる可能性があることを意味しますか？ さて、これは私が以前聞いたことのないものです。

たぶん、このソリューションはLXCコンテナでのみ機能します。 彼はそこでのコメント（LXCプロジェクトのリーダー）でも言っていたので、「私たちはsetuidヘルパー（newuidmapとnewgidmap）を使用します」そしてそれは「uidとgidマップをセットアップする」ことができます。 それで、おそらくLXC自体にもいくつかの必要なメカニズムがあります。そうでなければ、zfs acls部分を利用できませんか？ または多分私は間違っています。 私はこれをずっとフォローしているとは完全にはわかりません。

もう1つの興味深いリンク、今回はshiftfsについて、そしてその機能をoverlayfsに吸収する可能性についての議論。 もちろん、これはdockerがすでに使用している基盤となるファイルシステムです。

ただし、再マッピング機能がoverlayfsに実装された場合、基盤となるファイルシステムの代わりにzfsストレージドライバーを使用したい場合はどうなりますか？ ファイルシステムごとに実装されている場合、uid / gidを再マップする機能から除外する必要がありますか？ または、両方を別々に実装することはできますか？ 申し訳ありませんが、Dockerデーモンがそのような再マッピングを認識し、共通のAPIとフラグを提供する必要があるかどうかについて少しわかりません（fsドライバーレイヤーに渡すため）。 または、代わりに、ホスト側（ファイルシステム内、Dockerの外部）で手動でこのような再マッピングを実行する場合。 その側面も私には少し不明確なままです。

[編集]おっと、リンクを含めるのを忘れました！ ここにあります

https://lists.linuxfoundation.org/pipermail/containers/2018-June/039172.html

この問題はボリューム/バインドマウントに関するものなので、コンテナのファイルシステムとは別に

オーバーレイにshiftfs機能が組み込まれている場合は、bindmountのuid / gidシフトを過度に使用しますが、サポートされていないシステムでは他の何か（または何も）にフォールバックする必要があります。

Podmanは、ルートレスのDockerドロップイン代替品ですhttps://www.youtube.com/watch?v=N0hSn5EwW8whttps://podman.io/ 。 podmanでは、rootが使用されないため、ユーザー権限が正しく処理されます。 この問題のため、私たちのチームはPodmanに切り替え、非常にうまく機能しました。

これは意味がありません。
同じ問題が当てはまります。
dockerにはルートレスモードもあることに注意してください。

次のコマンドでPodmanをテストできます。 PodmanにはDockerとは異なり、個別のデーモンがなく、すべてがpodmanコマンドを実行するユーザーの下で実行されます。 したがって、podman内で作成されたファイルは、 podman run ...コマンドを実行したユーザーが所有します。

kkimdev<strong i="8">@ubuntu</strong>:~$ mkdir podman_test
kkimdev<strong i="9">@ubuntu</strong>:~$ ls -agh podman_test
total 8.0K
drwxrwxr-x 2 kkimdev 4.0K Jun 27 04:23 .
drwxr-xr-x 8 kkimdev 4.0K Jun 27 04:23 ..

kkimdev<strong i="10">@ubuntu</strong>:~$ podman run --rm -it -v ~/podman_test:/podman_test alpine
/ # cd /podman_test/
/podman_test # touch test_file
/podman_test # ls -agh
total 8K
drwxrwxr-x    2 root        4.0K Jun 27 02:24 .
drwxr-xr-x   20 root        4.0K Jun 27 02:24 ..
-rw-r--r--    1 root           0 Jun 27 02:24 test_file

/podman_test #

kkimdev<strong i="11">@ubuntu</strong>:~$ ls -agh podman_test/
total 8.0K
drwxrwxr-x 2 kkimdev 4.0K Jun 27 04:24 .
drwxr-xr-x 8 kkimdev 4.0K Jun 27 04:23 ..
-rw-r--r-- 1 kkimdev    0 Jun 27 04:24 test_file

これはpodmanを宣伝するのに適切な場所ではありません。この問題の解決に役立つ具体的な技術的な詳細がどのように機能するかについての詳細がある場合は、特に問題の潜在的な解決策として、それらを議論することが適切です。現在コメントしています。 これまでのところ、これはそうではありませんので、この議論を他の場所で行ってください。

podmanのアーキテクチャがDockerとは大きく異なるため、この問題の深刻度や問題が軽減されるため、Dockerがこの1つの問題を解決するためだけに動作方法を完全に変更することはできません。 Dockerがそのように構造化されている理由はたくさんあり、その歴史をすべて無視するのは率直に言って不信です。

@tianonはい、もちろん、両方のアプローチには賛否両論があります。 podmanでコンテナをターゲットユーザーと一緒に実行すると、この技術的な問題、つまり「root以外のユーザーとしてのボリュームのマウント」が具体的に解決されるという理由だけで、podmanについて説明しました。

上記のコメントで作成した「test_file」の許可をご覧ください。 最初に「〜/ podman_test」ディレクトリをマウントし、podmanコンテナ内に「test_file」ファイルを書き込みます。 次に、ユーザーがコンテナの外に出ると、ファイルがrootではなく「kkimdev」によって所有されていることがわかります。

問題は、Dockerの問題を修正するための提案は、Dockerの問題追跡システムでそれほど建設的ではない「Dockerを使用しない」ということです。

はい、 podmanは別の方法で設計されているため、この問題はそのツールにとって重要ではありません。これは問題ありませんが、ここではまったく話題になりません。 ルートレスにはさまざまなトレードオフがあり、一部の人にとっては問題ないものもあれば、そうでないものもあります。 時間の経過とともに（そしてほとんどの場合カーネルの改善により）改善されていますが、ここにいるすべての人にとって一般的なソリューションではありません。

これには、上記で詳細に説明したように、カーネルの変更または一般的なソリューションのシムが必要です（ @ cpuguy83などは、この問題を一般的な方法で解決するために取り組んでいます）。

Dockerは、この特定の問題を2013年から開いており、ほぼ6年後、視界を簡単に改善することはできません。 Podmanは、Dockerとの互換性を確保するように設計されていますが、Dockerの設計上の欠陥も解決します（スーパーユーザーのDockerデーモンを必要としない非特権ユーザーとしての実行を含む）。

ユーザーが他の人にGitHubの問題についてアドバイスを与えることができれば、それはまったく問題ありません。 これはコミュニティです。 役立つものは何でもお気軽にお勧めします。

Dockerがそのように構造化されている理由はたくさんあります。

grepもそうです。 しかし、誰かがより速く検索する必要がある場合でも、 ripgrepをお勧めします。 grep課題追跡システムでも。 ユーザーの問題を解決し、ユーザーを満足させる限り、誰の問題追跡システムであるかは問題ではありません。

Podmanが機能しない場合：問題ありません！ しかし、インフラストラクチャでdockerをpodmanに置き換えるだけでよいため、他の人を助ける場合は、そうさせてください。

Podmansの主な議論は、デーモンを実行しないということであり、それに対する私の主な議論です。 再起動後にコンテナを元に戻すにはどうすればよいですか？ 私は手でそれをしません、そして他のすべてはただ悪いデザインです。 また、Dockerコンテナをユーザーが所有するのではなく、システムが所有するようにします。これはルートを意味します。
Podmanを使用しているのがあなただけの場合、Podmanは理にかなっています。

そして、問題を解決するには： COPY --chown ...:...でコンテナを作成します！

また、Dockerにはそのような問題はなく、私にとっても重要なDockerサーバーをリモートで制御できます。

実行中のコンテナからポッドを生成するツールもありますが、クリーンな方法でゼロから構築する必要があるため、お勧めしません。

私たちは今トピックに戻るべきだと思います：私見最初のアドバイスは大丈夫でしたが、他のすべてはこの問題を爆破し、何も解決しません。

再起動後にコンテナを元に戻すにはどうすればよいですか？ 私は手でそれをしません、そして他のすべてはただ悪いデザインです。

さて、 Podmanはsystemdとネイティブに統合されています（ほとんどすべての最新のGNU Linuxディストリビューションのほぼすべてのもののように）。 したがって、「2つの」ブートシステムを維持する必要はありません（最初にsystemdでDockerデーモンを起動し、次に別の構成でコンテナを起動するための別のラウンドを実行する必要があります）。 したがって、Podmanを使用すると、systemd（つまり、おそらくすでにインストールして実行しているシステム）を使用してすべてを制御できます。

また、Dockerコンテナをユーザーが所有するのではなく、システムが所有するようにします。これはルートを意味します。

あなたがそれを望まなければ、それは完全に大丈夫です。 Podmanをスーパーユーザーとして実行することはできますが、もう実行する必要はありません。 一般に、これは悪い考えと見なされ、攻撃対象領域を増やします。誰かがDockerデーモンを悪用できる場合、その人はシステム上の_すべて_を制御できるからです。

Podmanを使用しているのがあなただけの場合、Podmanは理にかなっています。

このステートメントは意味がありません。 Podmanを使用すると、単一のシステムに分散できます。これは、同じシステムで多くの人が作業している場合に特に意味のある機能です。

そして、問題を解決するには： COPY --chown ...:...でコンテナを作成します！

ここでの問題は、_runtime_でのコンテナのボリュームの_mounting_です。 これは、イメージの構築とはほとんど関係がありません。

また、Dockerにはそのような問題はなく、私にとっても重要なDockerサーバーをリモートで制御できます。

この投稿が含まれているブログについて正確に言及しているのはおかしいです。 ただし、両方の実装のネットワークの詳細についてはあまり経験がありませんが、理解したように、podmanは可能な限り最小限のネットワークルールから開始し、特権のないユーザーはvethペアを設定できません。

明確にするために、ルートレスDockerでもpodmanと同じ効果を得ることができるはずです。
これは、dockerdがユーザーとして実行されており、コンテナー内のrootがUIDにマップされているためです。

これには欠点があり、もちろん、デーモンを複数のユーザーと共有する場合は機能しません。
https://get.docker.com/rootless

2019年6月27日午前7時52分、AlexanderAdamnotifications @ github.comは次のように書いています。

私たちは今トピックに戻るべきだと思います：私見最初のアドバイスは大丈夫でしたが、他のすべてはこの問題を爆破し、何も解決しません。

@ SuperSandro2000 https://github.com/SuperSandro2000 、ただし、ステートメントの応答については、ここをクリックしてください。
https://podman.io/blogs/2018/09/13/systemd.html https://osric.com/chris/accidental-developer/2018/12/docker-versus-podman-and-iptables/ https：/ /osric.com/chris/accidental-developer/2018/12/using-docker-to-get-root-access/
—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示https://github.com/moby/moby/issues/2259?email_source=notifications&email_token=AAGDCZXX2UQCG7LUVH57V6LP4TH2DA5CNFSM4AI3DP unsubscribe-auth / AAGDCZX437HJP4M6XG3SEY3P4TH2DANCNFSM4AI3DP6Q 。

@alexanderadam

ここでの問題は、実行時にコンテナのボリュームをマウントすることです。 これは、イメージの構築とはほとんど関係がありません。

私の解決策は、ディレクトリをマウントせず、可能であればコンテナでベイクすることでした。

ポッドマンの音はいいのですが、今のところ原因を切り替えません。私には何の利点もありません。 とにかく説明してくれてありがとう。

コンテナ内のApacheがwwwユーザーで実行されている場合、 podmanでも同じ問題が発生します。 https://github.com/containers/libpod/issues/3990

解決策は、コンテナー内にrootユーザーがいない場合に、コンテナーからホスト上のUIDにwwwユーザーをマップすることです。 それが可能かどうかはわかりません。

--read-onlyで実行する場合（ readOnlyRootFilesystem Kubernetesポリシーと同じように）、以下を実行できます。 これは、 @ jpetazzoが提案していた回避策に基づいています。

• Dockerイメージは、uid = 1001およびgid = 1001のユーザーを作成して使用します
• これとは別に、Dockerボリュームを作成します
• uid：gidを1001にchownします
• アプリケーションの実行時にそのイメージをマウントします。

Dockerfile：

FROM ubuntu

RUN groupadd -g 1001 appgroup && \
    useradd -u 1001 -g appgroup appuser

USER appuser

それで：

$ docker build . -t test
$ docker volume create somedir
$ docker run -v somedir:/some_dir alpine chown -R 1001:1001 /some_dir

これで、Dockerイメージを実行してボリュームをマウントするとき、/ some_dirは目的のユーザーに属します。

$ docker run -it --read-only -v somedir:/some_dir test ls -lrt

...
dr-xr-xr-x  13 root    root        0 Nov  4 15:22 sys
drwxr-xr-x   2 appuser appgroup 4096 Nov  5 09:45 some_dir
drwxr-xr-x   1 root    root     4096 Nov  5 09:45 etc
...

$ docker run -it --read-only -v somedir:/some_dir test touch /some_dir/hello
$ docker run -it --read-only -v somedir:/some_dir test ls -lrt /some_dir

-rw-r--r-- 1 appuser appgroup 0 Nov  5 09:52 hello

スレッドで簡単に失われるため、chownedシンボリックリンクはおそらくほとんどのシナリオで機能することをもう一度指摘します。 欠点は、何らかの方法で設定する必要があることです。これは、多くの場合、エントリポイントを、元のコマンドを実行するスクリプトに置き換えることを意味します。

https://github.com/moby/moby/issues/2259#issuecomment -466094263

+1

これは私がdockerで抱えている最も厄介な問題だと思います。これがすでに開いている時間を見ると、他の多くの人には当てはまらないことがわかりますか？

回避策を知っていれば問題ありません。 私の場合：

• ホストはLinuxです

  • コンテナ内のuid ==ホスト上の目的のuid-回避策は必要ありません
  • コンテナ内のuid！=ホスト上で必要なuid-いくつかのsetfaclコマンドを実行し、ホストユーザーとコンテナユーザーの両方にrwアクセスを許可します

• ホストはMacOSです-公式のDockerアプリではすべてが箱から出して動作します。

いくつかのsetfaclコマンドを実行し、ホストユーザーとコンテナユーザーの両方にrwアクセスを許可するだけです。

これは問題です。 すべてのDockerイメージに対していくつかのsetfaclコマンドを実行して、OSを検出したくありません。

これは実際には大きなセキュリティ問題でもあります。

シナリオ例：

• host1にはdockerがインストールされています
• host1には、Dockerコンテナで実行されている複数のサービスがあります。これらはすべて/docker/my-service-01|02|03|etcの下にローカルパスをマウントします。
• 各コンテナは異なるベンダーによって構築されており、それぞれが独自のuidおよびguidポリシーに従っているため、それに応じてchown -R uid.gid /docker/my-service-01...を要求します。

結果：

• ある時点で、 hostで作成された通常のユーザーまたはサービスユーザーは、意図も望まれていない/docker/my-service-01|02|03|etcへのフルアクセスを持ちます。
• 異なるベンダーの2つのコンテナーに「読み取り専用」としてボリュームをマウントする場合、 uid.gidが必要なコンテナーと一致せず、 chownを実行できないため、失敗します。 uid.gidポリシーがあり、それらは異なるためです:)

はい、以前にこの問題について詳しく説明しましたが、（当時）伝えられてきた重要な事実は、Linuxカーネルに再マップ可能なuidとgidを提供するための基盤となるサポートメカニズムがなかったことです。 したがって、このプロジェクト（moby / docker）がこの非常に望ましい機能を実装するには、カーネルに追加する必要があります。 そうでなければ、私たちはすでにこの機能を少し前に手に入れていただろう。 それが最初に見られたとき。

したがって、この議論を（今日）継続するための最も生産的な方法は次のとおりです。その状況のいずれかがその後変化したかどうかを確認します。 vger.orgでLinuxカーネルのメインライン開発者からの技術的な解説を探してください。 この根本的な欠落している機能については、カーネルで過去のパッチセット/マージ要求を探してください。 等

その下位レベルで何が起こっているのかをよりよく理解することを期待して。 つまずきは何でしたか？ パフォーマンスの問題でしたか？ セキュリティモデル/弱体化という点で異議はありましたか？ それはまだテーブルにありますか、それとも将来のロードマップにありますが、他の機能BとCを実装できるようになった後でのみ意味がありますか？ このカーネル開発はすべて他の場所で行われています。 他のチャネルで。

@DXistこれがLinuxではなくOSXで魔法のように機能するという事実は驚くべきことであり、それ自体が問題です。

@ dreamcat4の最後のコメントによると、誰かがこれのステータスが何であるかを確認するために新しい試みをしましたか？ カーネルで再マップ可能なuidとgidのサポートはありますか？ ここでの全体的なステータスはどうですか？

この問題を完全に解決するために、Linuxユーザー名前空間を使用しました。 他のプラットフォームとまったく同じように機能します（AFAICT）（コンテナーはバインドマウントされたボリュームをルートとして認識し、ホストはそれをdockerを実行しているユーザーとして認識します）。

ガイドはこちら： https ：//www.jujens.eu/posts/en/2017/Jul/02/docker-userns-remap/

@patrobinson +1