私たちがこれに行くなら、私は持っているのではなく、RUNPオプションに賛成です
すべてのコンテナが特権モードで実行されています。

2013年9月18日水曜日午後1時7分、Benjamin Podszun
[email protected] ：

現在、外部で特権操作を実行する方法はないようです。
dockerrun-privileged。

つまり、Dockerfileで同じことを行うことはできません。 私の最近
問題：コンテナー内で（encfs用の）fuseを実行したい。 インストール
ヒューズはすでにハックと醜い回避策で混乱しています（[1]と[2]を参照）、
mknodは失敗するか、特権ビルドステップなしではサポートされないためです。

現在の唯一の回避策は、を使用して手動でインストールを行うことです。
-privilegedを実行し、新しい「ヒューズベースイメージ」を作成します。 つまり、私は
公式のベースイメージから仕上げまで、コンテナ全体を説明することはできません。
単一のDockerfileで。

そのため、どちらかを追加することをお勧めします

• Dockerビルド-特権
  これは、run -privilegedと同じことを実行する必要があります。つまり、すべてを削除します。
  キャップの制限

また

• DockerfileのRUNPコマンド
  これは..よく..実行する必要がありますが、_P_rivilegesを使用します

ソースを見てみましたが、goでは役に立たず、見つかりませんでした。
残念ながら、概念実証を添付するための適切なエントリポイント。 :(

1： https ：
2：＃514（コメント） https://github.com/dotcloud/docker/issues/514#issuecomment -22101217

—
このメールに直接返信するか、 GitHubで表示して
。

ビクターVIEUX
http://vvieux.com

実際には、両方を実行する必要がある場合があります。つまり、RUNP +には「-privileged」が必要です。
国旗。

（「-privileged」を必要とせずに）RUNPのみに依存する場合は、
「このビルドは安全ですか？」
「-privileged」のみに依存している場合、情報を見逃します（
Dockerfile）「このアクションには拡張特権が必要です」。

両方の組み合わせが最も安全な方法だと思います。

2013年9月18日水曜日4:07 AM、Benjamin Podszun
[email protected] ：

現在、外部で特権操作を実行する方法はないようです。
dockerrun-privileged。

つまり、Dockerfileで同じことを行うことはできません。 私の最近
問題：コンテナー内で（encfs用の）fuseを実行したい。 インストール
ヒューズはすでにハックと醜い回避策で混乱しています（[1]と[2]を参照）、
mknodは失敗するか、特権ビルドステップなしではサポートされないためです。

現在の唯一の回避策は、を使用して手動でインストールを行うことです。
-privilegedを実行し、新しい「ヒューズベースイメージ」を作成します。 つまり、私は
公式のベースイメージから仕上げまで、コンテナ全体を説明することはできません。
単一のDockerfileで。

そのため、どちらかを追加することをお勧めします

• Dockerビルド-特権
  これは、run -privilegedと同じことを実行する必要があります。つまり、すべてを削除します。
  キャップの制限

また

• DockerfileのRUNPコマンド
  これは..よく..実行する必要がありますが、_P_rivilegesを使用します

ソースを見てみましたが、goでは役に立たず、見つかりませんでした。
残念ながら、概念実証を添付するための適切なエントリポイント。 :(

1： https ：
2：＃514（コメント） https://github.com/dotcloud/docker/issues/514#issuecomment -22101217

—
このメールに直接返信するか、 GitHubで表示して
。

@jpetazzo https://twitter.com/jpetazzo
最新のブログ投稿： http ：

合理的に聞こえます。 私にとって、この機能（デバイスノードを作成できる）は、Dockerでデプロイメントを作成する機能を作成または中断します。 私が助けることができれば（ほとんどの場合、ソースを調べてみましたが、これまで失敗しました。ビルドファイルで使用可能なコマンドはリフレクションを介して見つかったようです。config.privilegedをtrueに設定するrunpコマンドを追加しましたが、これまでのところ私はビルドとテストができません->スタック）私は喜んで時間を投資したいと思います。

RUNP + build -privileged勧めします。

_ @ shykes 、@ crosbymichael_の注意を

...そしてもちろん、それを実装する人を見つける必要があります☺
それはあなたが試してみたいものでしょうか（もちろん、コアチームからの適切なガイダンスとフィードバックがあります）？

最後の部分が私をターゲットにしていた場合：もちろん、そうしないでください。 私はすでにgoコードをいじっています（私が精通している言語ではありませんが、上記を参照してください：とにかく何が起こっているのかを理解しようとしています）。

いくつかのポインタ/誰かがいくつかの質問にpingを送信するので、私は確かにそれを試してみます。

私はRUNPまたはビルド特権で販売されていません。

。

一般的に、同じ入力のさまざまなビルドを導入するものは好きではありません。 そのため、引数や環境変数をビルドに渡すことはできません。

具体的には、「特権」への依存関係をあちこちに導入するのは好きではありません。これは、a）非常に大きく、b）明確に指定または定義されていない一連の機能を指定するためです。 これは、システム管理者がセキュリティをオールオアナッシングでバイパスするための大まかなメカニズムとしては問題ありません。標準のDocker実行環境では不十分な場合は「エスケープハッチ」です。 その点では、bind-mountsやカスタムlxc-confと似ています。

—
@solomonstre
@getdocker

2013年9月20日金曜日午後3時18分、Benjamin Podszun
[email protected]は次のように書いています：

最後の部分が私をターゲットにしていた場合：もちろん、そうしないでください。 私はすでにgoコードをいじっています（私が精通している言語ではありませんが、上記を参照してください：とにかく何が起こっているのかを理解しようとしています）。

いくつかのポインタ/誰かがいくつかの質問にpingを送信するので、私は確かにそれを試してみます。

このメールに直接返信するか、GitHubで表示してください。
https://github.com/dotcloud/docker/issues/1916#issuecomment -24844868

さて、たとえば、fuseを実行するDockerイメージを構築できるはずだということに同意しますか？
そのためには、mknodする必要があります。

私の見方では、これらのビルドがパラメーターによって異なる可能性はありません。ビルドは機能する（キャップ​​は現在よりも制限されていない/制限が少ない）か、失敗します（現状維持）。 同じビルドファイルの「バージョン」が異なるリスクはほとんどありませんよね？

私は今この問題に直面しています。 必要なイメージを構築するには、Dockerfileをbuildするのではなく、一連のrun -privilegedステップ+ commitステップを実行する必要があります。 理想的には、Dockerfileでイメージのビルド手順を表現するとよいでしょう。

mknodの操作にも関連していますか？
特権モードを必要とするアクションを正確に説明できる場合
あなたの場合、それは非常に役に立ちます！
ありがとう、

ねえ@jpetazzo 、メーリングリストから、これが私が直面している問題です： https ：//groups.google.com/forum/#！topic / docker -user / 1pFhqlfbqQI

コンテナ内で作成した（aufsやジャーナリングに関する何かを回避するために作成した）fsをmountしようとしています。 私が実行している特定のコマンドはmount -o loop=/dev/loop0 /db/disk-image /home/db2inst1 。ここで、 /db/disk-imageはdd if=/dev/zero of=disk-image count=409600作成され、 home/db2inst1はdb2を開始しようとしている場所です。

私が正しく理解していれば、インストールプロセス中に、AUFS以外のディレクトリ、つまりO_DIRECTをサポートするディレクトリが必要です。 その場合、Docker 0.7はAUFSの代わりにext4（およびブロックレベルのスナップショット）を使用するため、問題を解決するはずです。

これも+1。

メモリ設定とカーネル構成の変更が必要なパッケージ（Vertica DB、WebSphere MQなど）のインストールは、特権モードでのみ実行できます。

「特権」を使用した実行/ビルドに関しては、関心の分離を試みましょう。ビルド中、実行中、 docker runまたはその両方で必要になる場合があります。

必要に応じて、ビルドがステップ（またはそれ以上）に対してもう少し多くのアクセス許可を必要とする何かを実行できるようにすることが可能であるはずです。 プロジェクトにこれが必要で、Dockerfileの半分をシェルスクリプトに変換してビルドを呼び出し、特権モードでビルドを続行する必要があったため、「特権」ビルドがあると便利です。

ただし、sysctlを使用して一部の設定を変更できるようにするために、デフォルトで特権モードに完全に移行するべきではありません。 これは、イメージ構成またはコマンドライン引数を介して実行し、 docker run渡す必要があります。

右。 @ orikremer 、

/ sysまたは/ procにある場合、最善の解決策は、特権モードに切り替えるのではなく、代わりにモックを配置することです（変更はとにかく持続されないため）。

長期的には、モックファイルシステムが変更をキャプチャしてDockerfileディレクティブに変換し、ランタイムに「このコンテナにはそのような調整が必要」と指示する場合があります。

@jpetazzo画像を作成してから数日が経ちました。 AFAIR Verticaは、十分なメモリがなく、両方とも最大オープンファイルを変更しようとしていると不平を言っていました。
Dockerfileを使用してイメージを再作成し、レポートを返します。

関連する問題＃2080に注意してください。

@jpetazzoは、-privilegedなしでイメージの再

• Limits.confのnice：Verticaは/etc/security/limits.confに「dbadmin--nice0」を追加します。 非特権コンテナで実行しているときにそのユーザーに切り替えようとすると、「セッションを開くことができませんでした」というエラーが発生します。 特権コンテナスイッチでは、ユーザーはエラーなしで作業します。
• 開いているファイルの最大数：コンテナーで必要な最大数がホストで設定されている最大値よりも大きいため、ホストで/etc/init/docker.confを変更し、コンテナーで「limitnofile」を設定してからulimit-nを設定する必要がありました。 それは正しいアプローチですか？

そのユーザーに切り替えようとすると、

切り替えはどのように行われますか？ -privilegedがユーザーの切り替えにどのように役立つかわかりません。 私はおそらくここで何かが欠けています:-)

最大オープンファイル

私が正しく理解していれば、Verticalインストーラーは開いているファイルの最大数を非常に高い数に設定しようとします。これは、Dockerが-privilegedフラグを使用して非常に高い数で起動された場合にのみ機能します。 右？

ユーザーの切り替え- su dbadminはそのエラーで失敗します。
私は次の方法で複製することができました：

• 新しいイメージ（centos-6.4-x86_64）をプルし、非特権で実行します
• useradd testuser
• /etc/security/limits.confを編集し、「testuser --nice0」を追加します
• su testuser試してください->「セッションを開けませんでした」で失敗するはずです
  特権コンテナでは、 su testuserは正常に機能します。

最大オープンファイル-正解。 インストーラーは、ホストが持っているよりも高い数値に設定しようとします。 ホスト設定を増やすか、-privilegedを開始することによってのみ、これは機能します。

次のDockerfileを試してみました。

FROM ubuntu
RUN useradd testuser
RUN echo testuser - nice 0 > /etc/security/limits.conf
CMD su testuser

そしてそれはうまくいきます。 使用している画像の正確な名前は何ですか？
（ centos-6.4-x86_64を試しましたが、引っ張れないようです！）

@lukewpattersonコンテナ内でループファイルシステムを機能させる方法を教えてください。

@jpetazzoこの

FROM backjlack/centos-6.4-x86_64
RUN useradd testuser
RUN echo 'testuser - nice 0' >> /etc/security/limits.conf
RUN su testuser
RUN echo 'test' > ~/test.txt

失敗した：

ori<strong i="10">@ubuntu</strong>:~/su_test$ sudo docker build .
Uploading context 10240 bytes
Step 1 : FROM backjlack/centos-6.4-x86_64
 ---> b1343935b9e5
Step 2 : RUN useradd testuser
 ---> Running in b41d9aa2be1b
 ---> 2ff05b54e806
Step 3 : RUN echo 'testuser - nice 0' >> /etc/security/limits.conf
 ---> Running in e83291fafc66
 ---> 03b85baf140a
Step 4 : RUN su testuser
 ---> Running in c289f6e5f3f4
could not open session
Error build: The command [/bin/sh -c su testuser] returned a non-zero code: 1
The command [/bin/sh -c su testuser] returned a non-zero code: 1
ori<strong i="11">@ubuntu</strong>:~/su_test$

私は（追加することによって、PAMモジュールのデバッグオンdebugにpam_limits.so中線/etc/pam.d/system-authインストール） syslogに試み、 suもう一度/var/log/secure見つけたものです：

10月7日14：12：238be1e7bc5590 su：pam_limits（su：session）：「/ etc / security / limits.conf」から設定を読み取ります
10月7日14：12：238be1e7bc5590 su：pam_limits（su：session）：process_limit：処理中-USERの場合はnice 0
10月7日14：12：238be1e7bc5590 su：pam_limits（su：session）：「/ etc / security / limits.d / 90-nproc.conf」から設定を読み取ります
10月7日14：12：238be1e7bc5590 su：pam_limits（su：session）：process_limit：DEFAULTのソフトnproc1024を処理しています
10月7日14：12：238be1e7bc5590 su：pam_limits（su：session）：「nice」の制限を設定できませんでした：操作は許可されていません

次に、 strace d suプロセスを実行すると、次のシステムコールが失敗していることがわかりました。

setrlimit(RLIMIT_NICE, {rlim_cur=20, rlim_max=20}) = -1 EPERM (Operation not permitted)

これにより、 pam_limitsモジュールが障害を報告します。 これにより、 suが続行できなくなります。
興味深いことに、Ubuntuでは、 pam_limitsはデフォルトでsuに対して有効になっていません。 有効にしても、 setrlimit呼び出しは失敗しますが、 suは続行され、とにかく機能します。
監査コードに関連している可能性がありますが、よくわかりません。

さて、なぜsetrlimit失敗するのですか？ コンテナにはsys_resource機能がないため、あらゆる種類の制限を引き上げる必要があります。

limits.confディレクティブをコメントアウトするだけだと思います。
（ちなみに、 limits.conf直接追加するのは悪い習慣です。 limits.d別のファイルに移動する必要があると思います。）

注：Dockerで開くファイルの数の制限はすでに引き上げられているため、最大優先度の制限を引き上げることもできます。 それもうまくいくはずです！

これがお役に立てば幸いです。

そのDockerfileには、それ自体で次の行があります。

RUN su testuser

これを実行するコマンドはありません（そして、結果のシェルを後続のRUNコマンドに適用しません）ので、シェルを開こうとして本当に失敗し、そうすることが理にかなっているインタラクティブな場所にいない場合でも、私は驚かないでしょう（ docker buildはインタラクティブなプロセスではないため）。 今は確認する時間がありませんが、実際のコマンドをsuに渡して試してみる価値はあります。

@jpetazzo詳細な説明ありがとうございます。 Dockerの最大優先度を上げてみて、それが役立つかどうかを確認します。

（ちなみに、limits.confに直接追加するのは悪い習慣です。limits.dの別のファイルに移動する必要があると思います。）

同意しましたが、これはVerticaインストーラーコードであるため、回避しようとしています。

@tianonこれをインタラクティブシェル（/ bin / bash）で実行した場合も、同じことが起こります。

申し訳ありませんが、それでも試してみる価値はあったと思います。

ただし、Dockerfileではあまり意味をなさないその行に関するポイントは引き続き当てはまります。 あなたはおそらくもっとこのようなものが欲しかったでしょう（あなたが限界の問題を理解した後）：

RUN su testuser -c 'echo test > ~/test.txt'

@tianonあなたが正しい、それはあまり意味がありません。 これは、su自体が失敗することを示すためだけのものでした。

元の議論に戻るには：セキュリティの観点から（そして便利です！）ビルドプロセスで（そしておそらく通常のコンテナ実行で） setfcapとmknod機能を許可することは問題ないと思います良い）。 誰かがそれから生じる可能性のある問題を見ていますか？

@jpetazzoまったく逆です！ それは私が直面している多くの問題を解決するでしょう。 これは、実際のマシンのように動作/見えるDockerコンテナーを実行したい人にとって必要だと思います。

わかった！ それでよければ、＃2191「すべてのコンテナでmknodおよびsetfcap機能を有効にする」を優先してこの問題を閉じます:-)

そのようなシナリオについて知っていますか？

12時22分PMの日、2013年10月13日、unclejackオン[email protected] ：

2191https ：//github.com/dotcloud/docker/issues/2191はこれを解決しません

dockerbuild-privilegedを必要とするすべてのシナリオで問題が発生します。

—
このメールに直接返信するか、Gi tHubhttps：//github.com/dotcloud/docker/issues/1916#issuecomment-26224788で表示してください
。

@jpetazzo https://twitter.com/jpetazzo
最新のブログ投稿：
http://jpetazzo.github.io/2013/10/06/policy-rc-d-do-not-start-services-automatically/

@jpetazzoこれは、Dockerfileを使用してオペレーティングシステムイメージを構築する場合に必要です。

コメントを編集するときに誤って削除してしまいました。

Dockerfileですべてを実行しないと、これがどのように見えるかを見てください。

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh

build.sh

docker build -t mybuild .
docker run -i -t -privileged -cidfile mybuild.cid mybuild /root/build.sh
buildcid=`cat mybuild.cid`
rm mybuild.cid
docker commit $buildcid mybuild-final

これは、Dockerfileまたはdocker build -privilegedにrunpがないことを回避することを余儀なくされているため、Dockerfileが役に立たなくなり、Dockerfileのような機能を複製するツールを作成する必要があります。

明らかに、Dockerfileはrunpまたはdocker build -privilegedではるかに便利です：
runpの例：

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh
runp /root/build.sh

docker build -privileged例：

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh
run /root/build.sh

@unclejack ：申し訳ありませんが、私の質問は十分に正確ではありませんでした！
私が意味したのは、「（mknodとsetfcapに加えて）正確にどの権限が必要ですか？」ということでした。

@jpetazzo言うのは難しいですが、何が必要かを理解するために、これをなんとかして監査する必要があります。 ファイルシステムのマウント、ループバックマウントされたブロックデバイスおよびその他のいくつかの使用。

イメージのビルドに関しては、少なくとも3つの個別のニーズがあります。 docker buildに必要なアクセス許可、dockerを使用してコンテナーを実行するときに必要なアクセス許可、ビルド、実行、またはその両方のプロセス（sysctlなど）の実行時のニーズです。 。

docker build -privileged （または本当に必要なコマンドにのみ-privilegedモードを使用する場合はrunp ）があると便利だと思います。

ああ、マウントは間違いなく大きなものです。 これは非常に有効なユースケースであり、一般的なケースでは許可したくないと思われます。 問題を再開します。

@jpetazzo RE：PAMモジュール（Verticaもインストールしています）lxc.cap.dropからsys_resourceを取り出した後、dockerを再コンパイルすることをお勧めしますか？

たぶん、これらの制限のいくつかは、docker.confファイルを介して設定できますか？

Docker自体が限られた機能セットで実行されている可能性があるため、Dockerがコンテナーに委任するためにこれらの特権を使用できない可能性があることを考慮する必要があります。 これは、ネストされたDockerシナリオで＃2080の土地を発行する場合に特に当てはまります。これにより、非特権のネストされたDockerが許可される可能性があります。

'runp'や '-priviledged'などのソリューションがすべてのDocker環境で成功を保証されるとは限らないことを除いて、これによって何も変わるわけではありません。 このようなコマンドを追加するとき、およびそれらを文書化するときは、これを考慮する必要があります。

@ramarnat @jpetazzo Verticaのインストールと素晴らしいレベルの問題のループを閉じるためだけに、
docker.confで適切な制限を設定しようとしましたが、それは機能せず、bash特権を実行して手動でインストールする必要がありました。

@orikremer @jpetazzo lxc_template.goからsys_resourceを削除し、dockerを再コンパイルすることで、インストールを実行できました。 プルリクエストを出すことはできますが、lxc設定からそれを削除することのセキュリティへの影響について他の人が意見を述べるのを待ちます。

@ramarnat ：シナリオによっては、sys_resourceを削除しても問題ないと考える人もいます。 他の人にとっては、それは問題になるでしょう。

基本制限をもっと高いものに増やす可能性があります（ファイル記述子もElastic Searchの問題です）。 これは、「最小限のDockerランタイムが1,000,000個のファイル記述子を処理できる必要がある」と主張するようなものです。 Dockerが起動時に制限を引き上げることができない場合、Dockerは警告を発行して続行します（メモリ/スワップコントローラーグループの場合と同様）。

ただし、これはマウント/ループのシナリオを修正しません（私はまだこれで眠っています）。

@jpetazzoは、lxc_template.goのハードコードされた値をオーバーライドする方法を提供するかもしれません。 コマンドライン-lxc_confを使用したシナリオにはすでに何かがありますが、これらのlxc configディレクティブの.dropの性質では機能しません-試してみました！

まあ、それは可能性ですが、それは異なるコンテナ化システム間の将来の互換性を壊す良い方法でもあります:-)これ以上良いものが見つからないかどうかを確認します。

非特権モードで/ dev / loop *をホワイトリストに登録できますか？ 問題は、他のコンテナのループマウントされたファイル、またはホストのファイルにアクセスできる可能性があることだと思います...

@solomonstre
@docker

2013年10月17日木曜日午後6時9分、JérômePetazzoni
[email protected]は次のように書いています：

まあ、それは可能性ですが、それは異なるコンテナ化システム間の将来の互換性を壊す良い方法でもあります:-)これ以上良いものが見つからないかどうかを確認します。

このメールに直接返信するか、GitHubで表示してください。
https://github.com/dotcloud/docker/issues/1916#issuecomment -26565782

@jpetazzoそれは本当ですが、

@solomonstre重要なのは、 docker buildを特権モードでビルドできるようにする方法が必要だということです。 / dev / loop *へのアクセスを許可しても、特定のユースケースでは役に立ちません。

@solomonstre ：/ dev / loopのホワイトリストへの登録は、 。DMブランチを使用すると、すべてに読み取り/書き込みアクセスが許可されるためです（DMブランチのデフォルトの動作では、ループデバイスを使用してプール）。

一部のビルドでは、ループデバイス、マウントなどが必要になることを理解しています。 オプションを確認しましょう：

1. docker build -privileged
   便利ですが、「通常のビルド」と「特権ビルド」の間に線を引きます。 特権ビルダーを必要とする非常に便利なイメージがある場合、パブリックビルダーでそれをビルドすることは困難です。 たとえば、誰かがビルドを自動化するサービスを開始した場合、おそらく特権ビルドを提供しません（または、追加のセーフガードを使用する必要があります）。
2. ビルダーでパーミッションを少し緩和します
   これは、（少なくとも）cap_sysadminを有効にし（これにより、妄想的な私は少し震えます）、おそらく各ビルダーに1つまたは2つのループデバイスを与えることを意味します。 これにより、並行して実行されるビルダーの総数が制限されます。 ただし、ビルドは高速であり、さらに重要なのはアクティブなプロセスであると想定されているため、大したことではありません。 IEで50のビルドを並行して実行している場合、kickass I / Oサブシステムを備えたマシンがない限り、それらのビルドはあまり進行しません。
3. ビルドを仮想化/分離の別のレイヤー内にラップします。
   Docker内でビルドを直接実行する代わりに、QEMU-in-DockerやUML-in-Dockerなどを実行します。 これは、追加の作業がないことを意味するため、Docker開発者の観点からは優れたソリューションです。 これは、複雑さの別のレイヤーを処理することを意味するため、DOckerユーザーの観点からは不十分なソリューションです。

docker build -privileged`を許可するのが正しい解決策であるかどうか疑問に思います。同時に、オプション3の透過的な実装を可能にするフックについて考えてください。私が「Dockerビルドプロバイダー」であると仮定します。誰かが特権ビルドを要求しました。私がしなければならないのは、サンドボックス環境内でビルドプロセスを実行するために何かを挿入することだけです（QEMUとUMLは明らかな候補ですが、他の人も機能する可能性があります。これらは単なる便利な例です）。

皆さんはどう思いますか？

@backjlack 、ビルドされたらそのコンテナをどのように使用するか聞いてもいいですか？ 何
あなたがそれを正確に「dockerrun」すると起こります、アプリケーションは何ですか？ ただ
このためのユースケースの感覚をつかもうとしています。

2013年10月18日金曜日午前9時59分、JérômePetazzoni
[email protected] ：

@solomonstre https://github.com/solomonstre ：ホワイトリストに登録する/ dev / loopは、
IMHO、大したことはありません。DMブランチを使用すると、読み取り/書き込みが可能になるためです。
すべてへのアクセス（DMブランチのデフォルトの動作は
プールを格納するためのループデバイス）。

一部のビルドにはループデバイス、マウントなどが必要になることを理解しています
もの。 オプションを確認しましょう：

1. docker build -privileged便利ですが、間に線を引きます
   「通常のビルド」と「特権ビルド」。 あなたがたまたま持っているなら
   特権ビルダーを必要とする便利な画像、それは難しいでしょう
   パブリックビルダーでビルドします。 たとえば、誰かが自動化するサービスを開始した場合
   ビルド、彼らはおそらく特権ビルドを提供しないでしょう（または彼らは持っているでしょう
   追加のセーフガードを使用するため）。
2. ビルダーでパーミッションを少し緩和するこれは（少なくとも）
   cap_sysadminを有効にする（これにより、妄想的な私は少し震えます）、そして多分
   各ビルダーに1つまたは2つのループデバイスを提供します。 これは合計を制限します
   並行して実行されているビルダーの数。 でも大したことではありません
   ビルドは高速で、さらに重要なことに、アクティブなプロセスであると想定されています。
   マシンがない限り、50のビルドが並行して実行されている場合はIE
   キックアスI / Oサブシステムを使用すると、これらのビルドはあまり進行しません。
3. ビルドを仮想化/分離の別のレイヤー内にラップします。
   Docker内でビルドを直接実行する代わりに、次のようなものを実行します
   QEMU-in-Docker、またはUML-in-Docker。 これはDockerのクールなソリューションです
   追加の作業がないことを意味するため、開発者の視点。 これは貧しいです
   DOckerユーザーの観点からのソリューション。
   複雑さの別の層。

正しい解決策は、dockerbuild-privileged`を許可することであるのではないかと思います。
同時に、透明にすることができるフックについて考えてください
オプション3の実装。私が「Dockerビルドプロバイダー」であると仮定します。
誰かが特権ビルドを要求します、私がしなければならないのは挿入することだけです
サンドボックス内でビルドプロセスを実行するための何か
環境（QEMUとUMLは明らかな候補ですが、他のものは機能する可能性があります
それも; それらは単なる便利な例です）。

皆さんはどう思いますか？

—
このメールに直接返信するか、Gi tHubhttps：//github.com/dotcloud/docker/issues/1916#issuecomment-26612009で表示してください
。

+ 1-ヒューズをインストールするためのmknode機能（S3バケットをマウントするため）またはDockerfilesで特権実行を実行する機能が欲しいです。 まだ最善の解決策が何であるかわからない。

+1。 この問題に関する更新はありますか？

+1
2013年11月17日午後11時31分、「yukw777」 [email protected]は次のように書いています。

+1。 この問題に関する更新はありますか？

—
このメールに直接返信するか、Gi tHubhttps：//github.com/dotcloud/docker/issues/1916#issuecomment-28676216で表示してください
。

また、JavaをインストールしようとしたときにFuseの問題が発生し、解決策に興味があります。 https://gist.github.com/henrik-muehe/6155333で提案されている回避策を試しましたが、RaspberryPiのDockerでは機能しません。

@jpetazzo ：長期的な解決策を模索しながら、-privilegedフラグを実装するという全体的な戦略が好きです。 そのために、この機能を実装するためのプルリクエストを送信しました。 現在のところ、このスレッドで前述した「RUNP」コマンドは実装されていないことに注意してください。

（人々が回避策を探してここに来る可能性があるので、これを「クロスポスト」させてください）

デバイスファイルを実際に使用していない場合（ただし、fuseパッケージの場合のように、post-instスクリプトの一部にすぎません）、次のことができます。

fakeroot apt-get ...

また：

dpkg-divert --local --rename --add /sbin/mknod && ln -s /bin/true /sbin/mknod`

それは意味のあることだと思いますが、最初のコメント/私のレポートにはすでに2つの回避策が含まれています。
公平を期すために、リストに新しいものを追加しましたが、問題は「ヒューズをインストールできません」ではありません。最初の投稿を読むと、パッケージをインストールするだけの人が何があっても役立つはずです。

本当の問題は、「mknodを呼び出す必要がある」（またはより一般的：これまで失敗した特権操作が必要）です。

@jpetazzoこれで修正できるでしょう？ https://lwn.net/Articles/564977/-それまでは、3）に進みます。これは、デバイスアクセスを分離することは、複雑さのもう1つの層であり、どこかで管理する必要があるためです。

ループ取り付けやヒューズが必要な機能であることも販売されていません。 ユーザースペースに（ヒューズ：実装​​が実行され、ループ：イメージファイルが）ファイルシステムをマウントするために、使用スペースのルートアクセス許可をコンテナーに与えるのは気が狂います。

ファイルシステムイメージまたはヒューズfsをマウントする必要がある場合は、コンテナーの外部にマウントして、ボリューム/バインドマウントとして使用できます。 docker iselfでリモートファイルシステムをサポートおよび管理することは、優れた機能かもしれませんが。 たぶんdockerfileMOUNT/ mount-point。

@discordianfish 3）はほとんど解決策ではありません。

＃2979はこの問題に役立ちますか？

私もこれの解決を待っていますが、mknodのせいではありません。 /etc/security/limits.d/を使用するユーザーの制限を設定するrpmでcentosコンテナーを実行しており、現在、次の要素で構成されるスレッジハンマーの回避策を使用しています。

RUN /bin/sed --in-place -e "s/^\s\?session.*pam_limits.so.*/\#\0/g" /etc/pam.d/*

Dockerfileの上部にあります。 （私たちはプロトタイピングをしているだけです、心配しないでください:)）

こんにちは@jpetazzo私はあなたが提案した両方のオプションを試しました。 を使用してイメージ「oracle_xe」を作成しようとしています

sudo dockerbuild-特権-toracle_xeDockerfileでこれら2つのコマンドを実行したい

RUNマウント-oremount、size = 3G / dev / shm
RUNマウント-a

しかし、それは機能しません。使用した構文が正しくないかどうかはわかりません。取得するエラーは次のとおりです。
フラグは提供されていますが、定義されていません：-privileged

RUNPを使用する2番目の選択肢も試しましたが、それも機能しませんでした。イメージをビルドすると、そのステップがスキップされます。

不明な命令RUNPをスキップします。 ビルドしようとしているDockerfileを送信できます。 この問題の解決にご協力ください。

ありがとう。

RUNPも「build--privileged」も実装されていないと思います。
可能であれば、Dockerfileを共有することを躊躇しないでください。 役に立つかもしれないので
私たちはあなたに「最も悪い」回避策を与えることができます:-)

7：44 AMで水曜日、2014年4月9日には、Manoj7 [email protected]は書きました：

こんにちはjpetazzo私はあなたが提案した両方のオプションを試しました。 構築しようとしています
を使用した画像「oracle_xe」

sudo dockerbuild-privileged -t oracle_xe becuase in my Dockerfile i
これらの2つのコマンドを実行したい

RUNマウント-oremount、size = 3G / dev / shm
RUNマウント-a

しかし、それは機能しません、私が使用した構文が
正しくない。 RUNPを使用する2番目の選択肢も試しましたが、それもしませんでした
動作します。イメージを作成すると、そのステップをスキップして次のように表示されます。
不明な命令RUNPをスキップします。 私がいるDockerfileを送信できます
構築しようとしています。 この問題の解決にご協力ください。

ありがとう。

このメールに直接返信するか、Gi tHubhttps：//github.com/dotcloud/docker/issues/1916#issuecomment-39972199で表示してください
。

@jpetazzo https://twitter.com/jpetazzo
最新のブログ投稿：
http://jpetazzo.github.io/2014/03/23/lxc-attach-nsinit-nsenter-docker-0-9/

こんにちは@ jpetazzo 、 RUNsudo umount / etc / hosts」を実行したいのですが、これに対する「最悪の」回避策はありますか？ ;）

@jpetazzo

oracle_xeイメージのビルドに使用したDockerfile

から*

MAINTAINER * * * * * * *

oracle-xe-11.2.0-1.0.x86_64.rpm.zip/appl/oracle/xe/oracle-xe-11.2.0-1.0.x86_64.rpm.zipを追加します
RUNマウント-oremount、size = 3G / dev / shm
RUNマウント-a
実行cd / appl / oracle / xe && unzip oracle-xe-11.2.0-1.0.x86_64.rpm.zip
実行cd / appl / oracle / xe / Disk1 && rpm -Uvh oracle-xe-11.2.0-1.0.x86_64.rpm
実行cd / appl / oracle / xe && rm oracle-xe-11.2.0-1.0.x86_64.rpm.zip
ENV ORACLE_HOME /u01/app/oracle/product/11.2.0/xe
ENV ORACLE_SID XE

私が最初に試したのは

sudo docker build -privileged -toracle_xe。

これは機能しませんでした、そして私はRUNPを使おうとしました
RUNPマウント-oremount、size = 3G / dev / shm
RUNPマウント-a
これも機能しませんでした。これらの2つの手順はスキップされました。

@gatoravi ：残念ながら、/ etc / hostsのアンマウントは簡単には機能しません。 なぜあなたはそれをする必要がありますか？ （私はあなたが非常に正当な理由を持っている可能性があることを理解していますが、あなたに最善の回避策を与えるためにそれらを聞いてみたいです...）

@ Bhagat7 ：そうです！ 質問：実行時とインストール時に、より大きな/ dev / shmが必要ですか、それとも実行時のみが必要ですか？ ビルド時の場合、どのステップが失敗し、どのように失敗しますか？

@jpetazzoツールのビルドプロセスの一環として、新しいIPアドレスを/ etc / hostsに追加したいと思います。
echo $IP $HOST >> / etc / hostsのようなもの。

docker run --privilegedを使用してからsudo umount \etc\hostsを実行すると、これは問題なく実行できますが、 docker commitを使用してコミットできないようです。したがって、 umountを繰り返す必要があります。コンテナを実行するときは、毎回手動で

どういうわけか\etc\hosts書き込み可能にして永続的にしたいのですが、 docker commitまたはDockerfileのどちらでもそれを行う方法が見つからないようです。

@jpetazzo

私はこの問題を抱えていました

bash-4.1＃/ etc / init.d / oracle-xe configure
Oracle Application Express [8080]に使用されるHTTPポートを指定します。

データベースリスナー[1521]に使用されるポートを指定します：1521

データベースアカウントに使用するパスワードを指定します。 同じことに注意してください
パスワードはSYSとSYSTEMに使用されます。 オラクルは、
データベースアカウントごとに異なるパスワード。 これは後に行うことができます
初期構成：
パスワードを確認します。

Oracle Database 11g Express Editionを起動時に起動しますか（y / n）[y]：y

OracleNetListenerを起動しています...完了
データベースの構成...完了
Oracle Database 11g ExpressEditionインスタンスを起動しています...完了
インストールは正常に完了しました。
bash-4.1＃cd /u01/app/oracle/product/11.2.0/xe/bin
ベース-4.1＃sqlplus
ユーザー名を入力してください：system
パスワードを入力してください： * **
しかし、私はこのエラーを受け取ります
ORA-01034：ORACLEは使用できません
ORA-27101：共有メモリレルムが存在しません
Linux-x86_64エラー：2：そのようなファイルまたはディレクトリはありません
プロセスID：0
セッションID：0シリアル番号：0
返されたコンテナ内のdf-h
使用されたファイルシステムのサイズ使用率使用率
tmpfs 64M 0 64M 0％/ dev / shm

したがって、tmpfsのサイズを3Gに増やしても、このエラーは発生しませんでした。 コンテナを次のように実行して解決しました
sudo docker run -privileged -i -t oracle_xe / bin / bash。 コンテナ内で2つのマウントコマンドを実行しました。 しかし、私はそれをそのようにしたくはありません。代わりに、Dockerfileに入れてビルドしたいと思います。

@gatoravi ：わかりました。 次に、さらに2つの質問があります。ビルド中に/ etc / hostsに追加のホストが必要ですか、それとも実行中にのみ必要ですか？ そして、なぜあなたはそれが必要なのですか？

@ Bhagat7 ：申し訳ありませんが、これに対するエレガントなソリューションはまだありません:-( 2つのDockerfileを使用することをお勧めします：

• すべてのステップ（より大きな/ dev / shmを必要とするものを除く）を実行し、コンテナーが特権モードで実行されているかどうかをチェックし、より大きな/ dev / shmをマウントし、特別な指図;
• さらなるステップを実行するための2番目のDockerfile（実行時に/ dev / shmも必要な場合を除き、今のところ特権のものが必要です）。

@jpetazzoユーザーに編集可能な/ etc / hosts /を含む画像（/ container）を提供して、そのファイルを変更するコードを作成できるようにします:)ホストを追加する必要がある理由については、私は '正直であるかどうかはわかりませんが、インストールの一部として、特定のホスト名がIPアドレスを指すようにします。

@ Bhagat7次の組み合わせを使用して、

1. https://github.com/wnameless/docker-oracle-xe-11g
   と
2. ホスト上..。

sysctl -w kernel.msgmni=4096
sysctl -w kernel.msgmax=65536
sysctl -w kernel.msgmnb=65536
sysctl -w fs.file-max=6815744
echo "fs.file-max = 7000000" > /etc/sysctl.d/30-docker.conf
service procps start

@mikewaters返信ありがとうございます。 Ubuntuの上にOracleXEを構築したと思います。 しかし、私はそれをCentos上に構築しようとしています。

@jpetazzoご提案ありがとうございます

こんにちは、みんな、

私はgoogle-chromeを使用しています。これは/dev/shmに書き込む必要があります。これは通常777のようで、ここでは755です。 /etc/fstab特定の構成を追加しようとしましたが、ビルドに変更を適用するためにmout -aを実行できません。 もちろん、基本的なchmodまたはchown試しましたが、どちらもビルドでは実行できません。

--privilegedモードでログインしているときにコマンドを使用すれば、すべて問題ありません。 しかし、他の人が説明したように、ビルドでこれを行う必要があります。

なにか提案を？

ありがとうございました。

@tomav 「/ dev / shm」権限の問題は実際には＃5126です。これは＃5131で修正され、すでにマスターにマージされています（次のリリースで予定されています）

@tianonありがとうございます。

今日、私はこのアイデアを思いつきました。データボリュームを管理するコンテナが必要です。 簡単ですが、私はvpsを使用しているので、これらのボリュームを暗号化する必要がありますが、通常どおり他のコンテナーに明確に提供します。 重要なのは、仮想ディスクに明確なデータがないことと、キーを削除して破棄する簡単な方法です。

コンテナーを配置するためのcryptfsの作成について、この記事で美しく文書化されているいくつかの手順に従いました： https ：//launchbylunch.com/posts/2014/Jan/13/encrypting-docker-on-digitalocean/

私はそうしようとはしていませんが、実際にはcryptfsがマウントされたコンテナを持っていることに注意してください。
したがって、暗号化されたファイルシステムは、Dockerを介したビルド中に作成、マウント、フォーマットする必要があります。

それは失敗します：

• ループデバイスを見つけようとすると：

+ losetup -f
losetup: Could not find any loop device. Maybe this kernel does not know
       about the loop device? (If so, recompile or `modprobe loop'.)

• 奇妙なことに、まったく同じdockerfileがループデバイスを見つけることに成功することがあります。

+ losetup -f
+ LOOP_DEVICE=/dev/loop1
+ losetup /dev/loop1 /cryptfs/disk
+ cryptsetup luksFormat --batch-mode --key-file=/etc/cryptfs/random /dev/loop1
setpriority -18 failed: Permission denied
/dev/mapper/control: mknod failed: Operation not permitted
Failure to communicate with kernel device-mapper driver.
Cannot initialize device-mapper. Is dm_mod kernel module loaded?

これを回避する方法はまだありますか？ （ディスクのマウント/フォーマット手順をrun移動する以外）

+1「dockerindocker」環境で特に役立ちます

+1すると、iptablesは非特権モードでは機能しません。これにより、ファイアウォールルールを設定しようとするものはすべて失敗します。

@PerilousApricot ：ただし、 RUNでiptablesルールを設定できたとしても、イメージはファイルシステムの状態のみを保持しているため、すぐに失われることに注意してください。 実行中のプロセス、ネットワークルート、iptablesルールなどについては知りません。

コンテナには特定のポートしかないので、それで問題ありません。
転送されました、私はファイアウォールに関心がありません、私はほとんどただ欲しいです
インストーラーはまったく成功することができます

アンドリューメロ

@PerilousApricotなるほど！ その場合、 iptablesを/bin/trueシンボリックリンクするのはどうですか？ それはインストーラーも幸せにするはずです。 （または、インストーラーをだますための同様のトリック？）

私はそれを試しましたが、インストーラーはからの出力も解析する必要があります
iptablesなので、それほど簡単ではありません:)

OK、これがハックになっていることは知っていますが、代わりに偽のiptables置くのはどうですか？ ダミー出力を生成するのはどれですか？

私はそれが素晴らしいことではないことを完全に理解しています。 しかし、真剣に、その種のインストーラーはそもそも修正されるべきです:)

DockerユースケースのDockerは、私をここに連れてきたものです。 具体的には、開発環境でlxcを使用しているため、lxcのdockerを使用します。開発者は、lxcでイメージをビルドできるようにしたいと思います。

docker indockerにもこれが欲しいです。 アプリケーションを実行する前にプルする必要のあるイメージがありますが、これはかなり大きいので、頻繁にプルしたりコミットしたりする必要docker buildなく、

この機能は必須のIMHOであり、 RUNPとbuild-privileged組み合わせが最適です。

私が直面した実際の/本番シナリオは、中間コンテナーでPuppetプロビジョニングを使用して構築されたDockerイメージです。 高度な機能を必要とする特定のサービスでは、ビルドでエラーが発生し、コンテナを-privilegedし、 ENTRYPOINTまたはCMDでパペットスクリプトを再適用する必要があります。

これにより、適切な状態を確保するためにpuppet構成を構築して適用する必要があるため（これには時間がかかるため）、コンテナー内の実際のサービスの起動時間が遅れます。また、実行中のコンテナーは実際の-privileged実行する必要がない場合があります。

上記が理にかなっていることを願っています。

@ jpetazzocentos6の上にWebサーバーを構築しようとしています。 dockerfileを介してiptableルールを構成するのに行き詰まっています。 @PerilousApricotの問題に似ています。

ところで：私は偽のiptablesなどのハックを実装するためのものではありません。

@pmoust ：昇格された特権を必要とするビルド操作についての詳細はありますか？ 私はおそらく問題を回避することをお勧めします、そして私はこれがあなたにとって満足のいくものではないかもしれないことを完全に理解しています。 それでも、どのような種類のインストーラー/ビルダーがそれらの特権を必要とするかを理解できれば幸いです...

@ passion4aix ：

@jpetazzoBitrockインストーラーはその一例です。 / tmpをtmpfsとしてマウントする必要があります。 http://answers.bitrock.com/questions/3092/running-installer-inside-dockerをご覧になることをお勧めします

@jpetazzoまたは基本的に任意のopenstackインストーラー

また、DockerコンテナでTokuMXを実行しようとすると、「transparent_hugepage」カーネルオプションを無効にする必要があるため、同様の問題が発生しました。

この問題について何か進展はありますか？ すでに1年以上経過しており、コメントを見ると、ほとんどの人がDockerfileから特権アクションを実行するために使用しています。

個人的には、「-特権」ソリューションを使用したビルドは選択しません。 インストール全体を特権として実行するのではなく、特権ユーザーとしてのみ一部のアクションを実行できるため、RUNPソリューションの方が優れています。 このように、少なくともRUNPをいつ使用するかを考え、必要な場合にのみ使用する必要があります。

このオプションを追加する必要がある場合、質問はもはや存在しないように思われますが、それが実行された場合のみです。 では、いつこの機能を期待できますか？

@diversitそれらは結合する必要があります。 したがって、コマンドラインで--privilegedを使用すると、 RUNPを使用できるようになります。そうしないと、信頼できないコード（DockerHubを含む）のビルドを行う人々にとって、これはセキュリティ上の悪夢になります。

ただし、Dockerfile構文の外部でこれを手動で実行できることにも注意してください。 ビルドプロセスでは、Dockerfileを読み取り、そこからコンテナーを作成して、イメージにコミットします。

@deas ：これはVOLUME /tmp実行することで解決できると思います。

@PerilousApricot ：少し詳しく説明していただけますか？ どんな種類のインストーラーでも特別な特権が必要な理由がわかりません。 （ええ、私は古い頑固なUnixの人です、それは私の欠点の1つです：D）

@diversit ：その特定のケースでは、マシンの管理者はビルドする前に透過的な

皆さん：Dockerfileが機能しない場合は非常にイライラすることを完全に理解しています。必要なのは、この--privileged / RUNPフラグだけです。 しかし、特権ビルドを開始すると、大量の処理が中断されます（たとえば、Docker Hubでの自動ビルド！）。そのため、非常に悪いと感じています。 そして、その価値については、特権ビルドを必要とするすべてのシナリオを調査し、それらを修正するのに役立てたいと思います：-）（これらのインストーラーが壊れていると私は確信しているので！）

@jpetazzo多くの/ほとんどのopenstackデプロイメントツール（例：https：//openstack.redhat.com/Main_Page）は、iptablesルールを設定します。 コンテナ化されたバージョンのアプリケーションをロール/デプロイできるようにしたいので、dockerfileをビルドして一度に実行できることが重要です。 iptablesルールは、コンテナー化プロセスを通じてネイティブに保持されないことは知っていますが、iptables-saveを通じて保持されるため、CMDプロセスで単純なiptables-restoreを実行すると、ルールが再ロードされます。 多くのデプロイツールは実際のデプロイを実行するためにpuppetやchefなどのCIツールを使用するため、iptablesを単に「スタブアウト」するのははるかに複雑です。したがって、互換性のあるスタブを作成して、すべてをエミュレートする必要があります。 「実際の」iptablesコマンドへの入力/出力。

さらに、「特権ビルドを必要とするDockerfileがある場合、機能X、Y、Zが失われる」と言うのは公正なトレードオフだと思います。

Oracle xeは、十分な共有メモリスペースがないと実行できません。 すべてのアカウントは、enufスペースを使用してremountimg tmpfsを実行すると、Oracle xeが起動して構成を完了できるようになります。マウントサイズを大きくすることで、大成功を収めると噂されています）

ビルド中
unmounttmpfsを実行します
で失敗する
umount：/ proc / kcore：umountにはスーパーユーザーである必要があります

私にRUNPを与えるか、私に死を与えてください....または....私に別の方法で何ができるかを見せてください:)

私の例は無効です。 @jpefazzoはまだ立っています:)私のOracle設定が問題を引き起こしていて、tmpfsサイズを調整する必要がないようです...少なくとも初期インストールでは。

CentOS 7.0でiptables問題が発生しています。これは、 runが--privileged実行された場合にのみ解決されますhttps://github.com/docker/docker/issues/3416

特権構築のサポートがなければ、この問題を回避する他の方法がわかりません

Step 24 : RUN iptables -I INPUT -p tcp --dport 80 -j ACCEPT
 ---> Running in 74ebc19b6935
iptables v1.4.21: can't initialize iptables table `filter': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.

@ buley ＃8299に追加されたsecurity-optsで、 --privilegedなしでこれを行うことが可能になると私は信じています

@jpetazzo VOLUME /tmpを使用すると、Bitrockインストーラーの問題がどのように解決されるかわかりません。 これはビルドでは機能する可能性がありますが、 /tmp 、そのイメージに基づくすべてのコンテナーのAUFSレイヤーをバイパスします。 結局のところ、根本的な原因はAUFSで修正する必要があるようです。

これが私のユースケースです：Dockerコンテナ内にchroot環境を構築したいと思います。 問題は、chrootにprocをマウントできないため、 debootstrapを実行できないことです。
W: Failure trying to run: chroot /var/chroot mount -t proc proc /proc
mount: permission denied
コンテナをrun --privilegedすると、（もちろん）機能します...
Dockerfileのchrootをデブートストラップしたいのですが（はるかにクリーンです）。 RUNPまたはbuild--privilegedを待たずに、それを機能させる方法はありますか？

どうもありがとう！

--privilegedまたはmountingの場合は+1。 glusterfsの構築を自動化する必要性

これは、BitnamiTomcatインストーラーからイメージを構築する私の努力に影響を与えています。 インストールプロセスの99％は問題なく実行されますが、tomcatを初めて起動しようとすると失敗し、catalina-daemon.outに次の出力が表示されます。

set_caps：機能の設定に失敗しました
カーネルが機能をサポートしていることを確認してください
ユーザー 'tomcat'のset_caps（CAPS）が失敗しました
戻り値が4のサービス出口

「--cap-addALL」を使用して作成したコンテナーで、Tomcatインストーラーを手動で正常に実行できます。 「dockerbuild」を使用して「dockerrun」、「dockercommit」を使用して手動で作成できるイメージを作成できないのは奇妙に思えます。 ビルドプロセス中に使用されるコンテナーは、「dockerrun」を使用して作成できるコンテナーと同じようにすべての機能を備えている必要があります。

@gilbertpilzビルドの移植性とセキュリティを確保するために、明示的にそれを行うことはできません。

@ cpuguy83-それは意味がありません。 次の場合は、必要なイメージを手動で作成できます。

docker run --cap-add ALL .... / bin / bash
bitnami-tomcatstack-7.0.56-0-linux-x64-installer.run..。
出口
docker commit...。

私が求めているのは、「dockerbuild」を使用してここで手動で行っているのと同じことを行う機能です。 片方でイメージを作成できても、もう片方では作成できない場合、「移植性とセキュリティ」がどのように「保証」されているのかわかりません。

さて、ホストの/ etc / passwdをビルダーにマウントし、たまたまそれを私に送信するDockerfileを提供しましょう。

このようなものは危険な場合があります。
また、-privileged（および--cap-add ALL）を使用すると、コンテナー内のユーザーがホストを完全に制御できることに注意してください。

これらを許可すると、DockerHub全体が危険にさらされます

@ cpuguy83 -

しかし、王国の鍵を同じように信頼していないことを誰かにsudoを与えることはありません。
ビルドは、信頼できないコードを可能な限り安全に実行できる必要があります。

ビルドで追加機能を有効にするためにCLIフラグを導入すると、ビルドの移植性が損なわれるため、まだ追加されていません。

とは言うものの、インストーラーは、それ自体がアクセスできないものを要求しているのはほぼ間違いなく間違っています。

丁度。 特権を必要とするdockerビルドを実行する機能を信頼していない人に与えるべきではありませんが、dockerはあなたが信頼している人がそうすることを妨げてはなりません。 これはポリシーの決定であり、ツールが私のためにポリシーの決定を行うと想定する場合、私はそれを本当に嫌います。 優れたツールを使用すると、私が行ったポリシー決定を明確かつ驚くことのない方法で実装できます。

あなたは全体像を見ていません。

このエコシステムには、サーバーや私のサーバー以上のものがあります。 たとえば、DockerHubは、信頼できないコードのビルドを常に行っています。

次に、DockerHubは、ビルドに機能を追加できるようにする必要はありません。 これが、DockerビルドをDockerHubにプッシュできないことを意味する場合は、問題ありません。

@ cpuguy83 @tianon @ jpetazzo -FUDが開始されると、私は声を上げざるを得なくなります。

これらを許可すると、DockerHub全体が危険にさらされます

srsly？
この機能の実装== TEOTWAWKI？

もちろん、DockerHubは、要求された--privilegedフラグを使用してdocker buildを実行することはありません。
あまり考えずに、それを実装するための少なくとも2つの明白な方法があります。

• フラグは、 docker -dを次のような新しいフラグで起動した場合にのみ機能します： --i-want-a-broken-security-model
• コードパスを有効にするコンパイル時フラグを作成します。

全体として、実装に対する歯ぎしりとエンジニアリングベースの理由の比率は、ここでは非常に高いようです。

@tamskyそして、ビルドはある場所では機能しますが、別の場所では機能しないという状況があります。
私は、どちらの場合も議論するのではなく、なぜ物事がそのようになっているのかを説明しています。

しかしまた...ほとんどのものはいかなる種類の特権アクセスも必要としません、そして特権アクセスを必要とするものは一般的にインストールが機能するためにそれを_本当に_必要としません。 これが原因で何かのインストールが失敗した場合、引用されたTomcatの問題の場合のように、そのインストーラーは壊れています。
このような機能を有効にすると、目前の実際の問題を実際に解決するのではなく、特権モードで実行するようになります。

@ cpuguy83

そして、ビルドはある場所では機能しますが、別の場所では機能しないという状況があります。

しばらくの間、_policy_が異なる世界に魔法のように移動し、一部のビルドはある場所では機能しますが、別の場所では機能しないことを想像してみてください...

なぜこれが大したことなのですか？
正確に誰が気にしますか？

Docker Incは、「すべてのビルドはどこでも機能する必要がある」という最小公分母のマントラ/要件が、実際の顧客のニーズを実際に無視している可能性があると考えていますか？

現在のポリシーは、顧客が「XをDockerに組み込む」ためのエンジニアリングコストを外部化することです。

Dockerでこの機能を提供する代わりに、「特権アクセスを必要としない」（実際には必要な）世界中のすべてのサードパーティプロジェクトを、Dockerビルドケースを処理するために最初に更新またはモンキーパッチする必要があります。

最終的に、Dockerが複数のプラットフォームで実行される場合、「dockerbuild」はすべてのシステムで同じように機能するわけではありません。 つまり、Windowsコンテナ、Solarisコンテナ、またはARM Linuxコンテナのビルドは、x86-64Linuxの場合と同じにはなりません。 これらのセキュリティコンテキストも、プラットフォームに応じて異なります。

つまり、 @ cpuguy83の場合、Dockerfileがユニバーサルのままであると常に想定できるとは限りません。 ただし、それらの間にある差異を最小限に抑える必要があることに同意します。 マルチアーチ/マルチプラットフォームのサポートを中心に最終的に行われる必要のある会話に、この機能を必要とするユーザーへの配慮を含める価値があるかもしれません。

たとえば、ロードされたアプリアーマープロファイルのため、ビルドはどこでも機能していません。
また、事前にキャッシュされたDockerコンテナをイメージにベイク処理した場合はどうしますか？

18. 11. 2014年、午前2時53分で、tamsky [email protected]書きました：

@ cpuguy83

そして、ビルドはある場所では機能しますが、別の場所では機能しないという状況があります。

ポリシーが異なる世界に魔法のように移動し、一部のビルドはある場所では機能しますが、別の場所では機能しないことを想像してみてください...

なぜこれが大したことなのですか？
正確に誰が気にしますか？

Docker Incは、「すべてのビルドはどこでも機能する必要がある」という最小公分母のマントラ/要件が、実際の顧客のニーズを実際に無視している可能性があると考えていますか？

現在のポリシーは、顧客が「XをDockerに組み込む」ためのエンジニアリングコストを外部化することです。

Dockerでこの機能を提供する代わりに、「特権アクセスを必要としない」（実際には必要な）世界中のすべてのサードパーティプロジェクトを、Dockerビルドケースを処理するために最初に更新またはモンキーパッチする必要があります。

—
このメールに直接返信するか、GitHubで表示してください。

この状況で「壊れた」のは「インストーラー」ではなく、Tomcat7です。TomcatをApacheおよびMySQLと統合するBitnamiのTomcatスタックを使用しています。 Dockerは、ソース、構成、統合、テスト、およびパッケージ化サービスのサプライチェーンの最後に位置しています。 Tomcatを「修正」するように要求すると、このサプライチェーンを利用できなくなります。 Tomcatを「修正」するよりも、手作業で必要なイメージを作成する（「-privileged」でコンテナーを起動し、インストーラーを実行し、コンテナーのスナップショットを作成するなど）方がはるかに簡単です。

+1
シェフの役割をdockerに移植することはできません。これらはすべて、ufwを使用してポートを開く必要があるためです。
ビルドに--privilegedを追加すると、これが修正されます。

+1。 Dockerfileのステップとしてdebootstrapを使用できません。

+1。 Dockerfileのステップとしてdebootstrapを使用できません。

Dockerfile / buildを使用してchrootをビルドするのは自然なことのように見えましたが、 @ fbruschが述べたのと同じ問題が発生し

FROM ubuntu:utopic
ENV HOME /root
RUN sudo apt-get update
RUN sudo apt-get install -y eatmydata
RUN for i in /usr/bin/apt*; do sudo ln -s /usr/bin/eatmydata $(basename $i); done
RUN sudo apt-get install -y debootstrap qemu-user-static binfmt-support
RUN sudo debootstrap --foreign --arch arm64 trusty ubuntu-arm64-chroot
RUN ls ubuntu-arm64-chroot
RUN sudo cp /usr/bin/qemu-aarch64-static ubuntu-arm64-chroot/usr/bin
RUN sudo cp /etc/resolv.conf ubuntu-arm64-chroot/etc
RUN sudo DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true LC_ALL=C LANGUAGE=C LANG=C chroot ubuntu-arm64-chroot /debootstrap/debootstrap --second-stage; sudo cat ubuntu-arm64-chroot/debootstrap/debootstrap.log

失敗する：

Step 11 : RUN sudo DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true LC_ALL=C LANGUAGE=C LANG=C chroot ubuntu-arm64-chroot /debootstrap/debootstrap --second-stage; sudo cat ubuntu-arm64-chroot/debootstrap/debootstrap.log
 ---> Running in 2654257e860a
I: Keyring file not available at /usr/share/keyrings/ubuntu-archive-keyring.gpg; switching to https mirror https://mirrors.kernel.org/debian
W: Failure trying to run:  mount -t proc proc /proc
W: See //debootstrap/debootstrap.log for details
gpgv: Signature made Thu May  8 14:20:33 2014 UTC using DSA key ID 437D05B5
gpgv: Good signature from "Ubuntu Archive Automatic Signing Key <[email protected]>"
gpgv: Signature made Thu May  8 14:20:33 2014 UTC using RSA key ID C0B21F32
gpgv: Good signature from "Ubuntu Archive Automatic Signing Key (2012) <[email protected]>"
mount: block device proc is write-protected, mounting read-only
mount: cannot mount block device proc read-only
 ---> de534a4e5458
Removing intermediate container 2654257e860a
Successfully built de534a4e5458

RUNP代わりに、ビルドフラグ--insecureます。
すべてのRUNコマンドについて、後続のコンテナーは--add-cap=allます。 特権は他のことも行うので、特権の代わりにこれは...
しかし実際には、フラグを変更せずに、必要に応じて完全なprivileged設定を実装するように変更することができます。

@ cpuguy83
Dockerビルドに渡されたフラグを使用して、RUNコマンドに特権を付与したり、RUNPコマンドを有効にしたりする必要はありません。 Dockerfileを調べて、コマンドなどでその中の何かを確認できることには価値があります。特権アクセスが必要であり、実行時にステップ10に進んでエラーが発生する代わりに、Dockerfileが最初にショートカットされます。特権を必要とするコマンドが含まれています。

このスレッドに私を導いたユースケースは、コンテナ内で実行できるようにしたいバインドマウントです。 現在、コンテナを特権モードで実行している場合にのみ実行できます。 これにより、開始時にコマンドをチェーン化するか、実行するプロセスの前にシステムのセットアップを完了するために実行されるinitスクリプトを使用する必要があります。

Dockerfileに含めることができれば便利です。

RUN mount --bind /dir1 /dir2

私のユースケースについて詳しく説明しますので、これは特権コマンドの要求を広範に与えるだけではありません。 私の特定のケースは、アプリケーション領域のディレクトリを接続されたデータボリュームにバインドマウントしたい場合です。

例えば

/usr/local/application/data -> /mnt/data 
/mnt/data -> HOST:/var/datasets/dataset1

これは、ボリュームマウントをアプリケーション領域に直接実行することでも解決できますが、それらを共通の場所に提供し、アプリケーションコンテナに特定のマッピングを実行させる方法を探しています。 これはシンボリックリンクでも解決できますが、一部のアプリケーションは、ターゲット/データフォルダーとしてシンボリックリンクを使用するとうまく機能しません。 また、アプリケーションがデータディレクトリの場所の構成をサポートしている場合は、ボリュームマウント領域を指すようにすることもできます。 私のユースケースでは、アプリケーションはデータディレクトリの場所の構成をサポートしていません。実際には、データとアプリケーションスペースを適切に分離するために、バインドマウントまたはシンボリックリンクを実行する必要のあるアプリケーションが常に存在します。

このA-> B-> Cを実行できるこの機能により、データコンテナーを汎用的に保つことができ、アプリケーションおよびデータコンテナーで--volumes-fromを使用して実現できるさまざまな組み合わせに柔軟性がもたらされます。

これは、 --volumes-fromのコンテナチェーンを使用することでも実現できます。

GenericDataContainer -> ApplicationDataContainer -> ApplicationContainer

これは正しい答えかもしれませんが、アプリケーションコンテナがバインドマウントを実行できる場合は、アプリケーションデータ用にさらに別のコンテナを作成する必要をなくすことができます。

今日、これは、コンテナーを特権モードで実行してからマウントバインドを実行することで実現できますが、以下に示すように、マウントバインドを永続化する方法はなく、コンテナーを起動するたびにリセットする必要があります。 。 シンボリックリンクはコミット時に保持されます。

私の特定のユースケースに対する答えは、3チェーンコンテナアプローチまたはinitスクリプトを使用することかもしれませんが、Dockerfileからコンテナ内（または他の特権コマンド）をバインドマウントする機能があると便利です。 データコンテナのチェーンでは解決できない、ホストからコンテナへのマッピングを含まない、説明できるバインドマウントのユースケースはおそらく他にもあります。

これに関連する問題か、それともバインドマウント固有の問題かはわかりませんが、Dockerコミットを実行したときに特権コマンドの結果が持続することで、Dockerイメージの構築とDockerイメージの実行を分離できます。 Dockerビルドを実行する領域を制御でき、エンドユーザーは非特権モードで実行できるコミットされたコンテナーのみを取得します。 バインドマウントとコミットを実行する場合、これは現在のところ原因ではありません。 ただし、これは/proc/mounts動作に関連している可能性があります。

これが簡単な例です

[root@ip-10-0-3-202 ~]# docker run --privileged -i -t --name test_priv centos:centos6 /bin/bash
[root<strong i="17">@d1d037cb170c</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

バインドマウントの例を作成し、シンボリックリンクの例も作成します

[root<strong i="6">@d1d037cb170c</strong> /]# mkdir /var/data1
[root<strong i="7">@d1d037cb170c</strong> /]# mkdir /var/data2
[root<strong i="8">@d1d037cb170c</strong> /]# mount --bind /var/data1 /var/data2
[root<strong i="9">@d1d037cb170c</strong> /]# ln -s /var/data1 /var/data3

ショーファイルは3つのディレクトリすべてから見られます

[root<strong i="13">@d1d037cb170c</strong> /]# touch /var/data1/test
[root<strong i="14">@d1d037cb170c</strong> /]# ls /var/data1
test
[root<strong i="15">@d1d037cb170c</strong> /]# ls /var/data2
test
[root<strong i="16">@d1d037cb170c</strong> /]# ls /var/data3
test

/proc/mounts更新して表示

[root<strong i="21">@d1d037cb170c</strong> /]# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 /var/data2 ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0

それを停止するコンテナを終了し、次に再開します

[root<strong i="25">@d1d037cb170c</strong> /]# exit
[root@ip-10-0-3-202 ~]# docker start -a -i test_priv
test_priv

/proc/mountsにバインドマウントがありません

[root<strong i="7">@d1d037cb170c</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

シンボリックリンクは存続しましたが、マウントをバインドしません

[root<strong i="11">@d1d037cb170c</strong> /]# ls /var/data1
test
[root<strong i="12">@d1d037cb170c</strong> /]# ls /var/data2
[root<strong i="13">@d1d037cb170c</strong> /]# ls /var/data3
test
[root<strong i="14">@d1d037cb170c</strong> /]#

バインドマウントを再設定します

[root<strong i="18">@d1d037cb170c</strong> /]# mount --bind /var/data1 /var/data2

コンテナを終了する代わりに、 ctrl+p ctrl+qでデタッチしてから、コンテナをコミットします

コンテナを新しいイメージとしてコミットし、非プライベートモードのイメージから新しいコンテナを開始します

[root@ip-10-0-3-202 ~]# docker commit test_priv test_priv
74305f12076a8a6a78f492fd5f5110b251a1d361e63dda2b167848f59e3799e2
[root@ip-10-0-3-202 ~]# docker run -i -t --name test_nonpriv test_priv /bin/bash

/proc/mounts確認してください
バインドマウントがありません。何が追加の/ proc / [sys、sysrq-trigger、irq、bus、kcore]マウントをトリガーしたのかわかりません

[root<strong i="5">@ba1ba4083763</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-ba1ba40837632c3900e4986b78d234aefbe678a5ad7e675dbab7d91a9a68469e / ext4 rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs ro,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
proc /proc/sys proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/sysrq-trigger proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/irq proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/bus proc ro,nosuid,nodev,noexec,relatime 0 0
tmpfs /proc/kcore tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,mode=755 0 0

シンボリックリンクは生き残った

[root<strong i="9">@ba1ba4083763</strong> /]# ls /var/data1
test
[root<strong i="10">@ba1ba4083763</strong> /]# ls /var/data2
[root<strong i="11">@ba1ba4083763</strong> /]# ls /var/data3
test
[root<strong i="12">@ba1ba4083763</strong> /]# exit

現在、 dindを使用して、ビルドステップで

皆さん、これが必要な場合は、「/ usr / bin / unshare -f -m -u -i -n -p -U -r- / path / to / binary」を試してください。 これにより、ビルド内にユーザー名前空間を持つコンテナーが作成されます。 必要に応じて、共有を解除するオプションを微調整できます。 私は実際にこれを使用して「/ sbin / capsh」を実行し、プロセスの機能をきめ細かく設定します。

これで特権ビルドのすべてのユーザーケースが解決されるとは言えませんが、一部のユーザーには役立つはずです。

これはDocker自体の一部になるはずであり、ユーザー名前空間の統合が進行中であるように見えることに同意します。

@saulshanabrookビルドでDockerイメージを実行することはできません。正確には実行できません。 いつかこれが可能になることを願っています。 私はこれについていくつかの調査を行い、VFSストレージを使用している限り、ビルド内から「ドッカープル」を実行できることを発見しました。 便利なことに、「dockersave」も機能します。

Dockerイメージを実行しようとしている人にとっては実際のソリューションではありませんが、「unshare」と「capsh」は機能するため、非特権コンテナーでコンテナーのようなランタイムを実行できます（ビルド中など）。 ）。 間違いなく、「docker run」を回避してこのステップを手動で実行し、イメージをdockerに再コミットすることが可能です。 今日は、すべてを弓で包んでいなくても、ほとんどの作業を行っています。 もちろん、最終的には、そのような機能はDocker自体に組み込まれる必要があります。

RUNPを介したDockerプルの+1

docker build特権を実行できないと、シェルとdocker commitを使用して手動でビルドすることが促進され、Dockerfileが無意味になります。 Dockerビルドに特権フラグを追加しても、ビルドと特権ビルドの間に線が引かれることはないと思います。 その線は、実行するフラグが追加されたときにすでに描画されており、サポートする必要があります。

+1これにより、任意の時点で再現可能なDockerコンテナが作成されます（dockerfileのみを実行する必要があります）

+1は、このような問題を回避するために、私のAnsibleベースラインの役割を完全に分解する必要があります。 Dockerを採用することで、既存のansibleコードの多くを使用できるようになることを本当に望んでいましたが、サイズのカスタムロールをすでに作成しているだけでなく、このような問題を回避する必要があります。

@lsjommerどのようなことを回避する必要がありますか？ --privilegedは、コンテナを実行するための完全に安全でない方法であり、コンテナ内のユーザーにホストへのフルルートアクセスを提供します。

これを実装しないと言っているのではありませんが、私たちが話していることについて実際に理解しましょう。

また、誰かがそれをやりたいのであれば、これは比較的簡単に実装できます...

@ cpuguy83これは、すべてのライブラリをインストールするためにDockerコンテナーに採用しようとしている標準の「ベアメタル」ベースラインの役割からのものであり、共有メモリを処理しますが、コンテナービルドでそれを気にする必要はないかもしれません。コンテナホストで実行するだけで済みますか？
http://pastebin.com/P3QQxjNQ

Dockerがリソース共有を処理する方法を完全には理解していないことを認めます。

@ljsommerしたがって、shmの設定はまったく別の獣であり、とにかくRUNコマンド間（または実際にdocker run ）には持続しません。

@ cpuguy83ええ、これは主に、コンテナホスト自体のベースラインに移行できる問題だと思っていた問題にぶつかったという点で私のせいだと思います。
返信に時間を割いていただきありがとうございます。文句を言う前に自分自身を適切に教育しなかったことをお詫びします。
;）

ビルドプロセス中にRUNP /特権に関するアイデアはありますか？
特定のIPアドレスへのDockerアクセス​​を制限するためにIPテーブルを設定するのは素晴らしいことです

RUNPや「dockerbuild--privileged」も必要です。

FROM ubuntu:latest
MAINTAINER xyz

RUN apt-get -qq update
RUN apt-get -yq install iptables

RUN iptables -t nat -I OUTPUT -p tcp --dport 443 -j DNAT --to-destination 127.0.0.1:8080 && iptables-save > /etc/iptables.rules

このDockerfileは、次のエラーのために機能しませんが、「dockerrun--privileged」を使用している場合は機能します...

getsockopt failed strangely: Operation not permitted

@ malcm 、@ sakurai-youhei： RUNPようなものがあっても、iptablesルールがファイルシステムに永続化されていないため、このシナリオでは機能しません。

説明させてください。 RUN xを実行すると、Dockerはx実行してから、ファイルシステムのスナップショットを取得します。 ファイルシステム外のもの（実行中のプロセス、ルーティングテーブル、iptablesルール、sysctl設定など）はDockerイメージに保存されません。

カスタムiptablesルールが必要な場合、1つの方法は次のとおりです。

• コンテナを開始します（例： --name myapp
• 別のコンテナ、特権、ワンショットを開始して、iptablesルールを設定します（例： docker run --net container:myapp --privileged iptablesimage iptables -t nat ...

それは理にかなっていますか？

@jpetazzo ：ご回答ありがとうございます。 私の場合、以下のように、iptablesルールをファイルシステム上のデータとして永続化するための2番目のコマンドを配置しました。 これにより、-privilegedオプションを指定してコンテナーを起動した後にiptablesルールをロードできるようになります。

RUN do-something-with-iptables && iptables-save > /etc/iptables.rules

RUNPも「build--privileged」もなければ、私は次のように書くことを余儀なくされます。

ADD iptables.rules /etc/

はい、これで十分かもしれませんが、リポジトリのDockerfileの横にiptables.rulesを追加する必要があります。

だから私はRUNPが欲しい（または優しくしたい）のです。 :)

@jpetazzo @strib
iptablesの問題、マウント、その他の特権操作以外に、対処すべきビルドシナリオが1つあると思います。

VMへの展開とベアメタルインストール用のアプライアンスを出荷します。 ただし、テストにはコンテナ環境を使用します。 次に、これらのアプライアンスの内部でコンテナーを実行します。 したがって、テストコンテナはdocker-in-dockerに基づいている必要があります。 ここで、テストイメージにプリロードする必要があるサービスイメージがあると想像してください（テスト時にサービスイメージがレジストリからダウンロードされないようにするため）。 d-in-dをベースとして使用するDockerfileのビルド中に、特権モードでd-in-dコンテナーを実行できないため、現時点ではそれを実行できません。dockerデーモンが起動しません。 "docker pull 「または「dockerload」は機能しません。

RHEL7ホストで実行しているときに、現在のユーザーがrootの場合、 suが失敗するという問題がありました。 奇妙なことに、現在のユーザーが他のユーザーである場合、 suは正常に機能しました。 とにかく、回避策は実行コマンドにフラグ--add-cap=SYS_RESOURCEを渡すこと

+1 docker runとdocker commitしたDockerfilesのスクリプトはばかげています。 この機能を含めてください。

この機能の必要性について+1。 グローバルな「セキュリティレベル」は、コンテナに与えることができる機能を制限する設定ファイルで設定できると思います。 （今日のように）安全なデフォルトがあるはずであり、システム管理者はそれを変更して、コンテナーがより多くの特権で実行できるようにすることができます。 このようなRUNP命令を含むdockerfileは、このようなグローバル制限のあるシステムで「このDockerfileをビルドするには次の機能が必要です....」などのメッセージで実行に失敗する可能性があります。

これにより、セキュリティと使いやすさのバランスが取れると思います。

また、evli独自のデータベースを使用してイメージを構築しようとしているときにもこの問題が発生します。このデータベース内には名前がありません。
dbは、dockerでは許可されていない大量のメモリを割り当てたいと考えています。

現在の回避策は、実行特権ステップと個別のコミットステップを使用した2フェーズビルドです。

たぶん、他の方法でメモリ割り当てを許可するようにdockerを構成できます。 独自仕様であるため、dbが実際に何をしたいのかを見つけるのは少し難しいです。

+1
この機能のために。
歴史的およびユースケースの例については、この重複を参照してください
https://github.com/docker/docker/issues/12138#issuecomment -90536998
デュープを指摘してくれてありがとう@ cpuguy83

私もこの問題を抱えています。特権フラグが指定されていない限り、Dockerビルド中にcifs共有にフックしようとすることは許可されていません。

これを実装するプルリクエストがあります。 そこで進捗状況を確認できます。 https://github.com/docker/docker/issues/12261

特権モードが必要な場合は、何らかの方法でホストを変更している可能性があります。つまり、イメージを消費しようとしている他のホストでこれらの変更を実行する必要があるため、イメージは移植できない可能性があります。

＃13171がマージされたら、これを閉じる必要があると思います。これにより、独自のビルダーのローリングが簡単になり、-privilegedが許可されます。
組み込みのdocker buildでこれが可能になるとは思いません。

したがって、 @ cpuguy83 、私が正しく理解している場合、この問題をサポートする方法は、 docker buildを完全に再実装することですが、追加のパラメーターを使用しますか？

他のパッチがプッシュされたら、追加機能を入力するために、自分のバージョンのdocker build （おそらくdocker pbuild ？）をまとめる必要があると思います。

この問題について何か進展はありますか？ 上記のPRを確認したところ、すべて失敗しました。
BUILD --privileged/--grantedオプションをより細かくして、イメージビルダー/所有者のみに制限されたホストリソースの特定のグループへのアクセスを許可することは可能ですか？

DockerfileでRUN docker pullを実行できるソリューションの場合は+1。

使用例：画像の変換とドキュメントの作成に多数のツールが必要ですが、ライブラリが競合しているため、これらのツールをすべて1つの画像にインストールすることはできません。 そのため、これらのツールの一部を個別の画像に分割し、すべてのツールを1つの画像、つまり画像内の画像に分散させたいと考えています。 そのため、DockerfileでRUN docker pullを実行したいと思います。

@ cpuguy83この問題は、誰もが満足できるように解決されたようには見えません。 私は絶対に、100％、ビルド中に/proc/sys/kernel/core_patternに書き込むのと同じくらい退屈なことをすることができる必要があります。

現在の世界では、 run回避策を介してこの特権操作を実行し、とにかくそのイメージをハブにプッシュすることができます。 さらに、私が作成したDockerfileは、ランダムに絶えず変化するパブリックリポジトリから取得されるため、厳密に再現可能ではありません。 知らなかった

1. 私の画像の一般消費は優先事項でした。
2. 彼らには、再現可能である必要がありました。

人々は、ビルドでprivilegedを取得するために、くだらない回避策を実行しようとしています。 私はあなたが間違いなくあなたのユーザーがいるところに行き、コアビルドツールでこれを許可するべきだと思います。 必要に応じて恐ろしいメッセージを追加します。

cc @thaJeztah 、この立場に共感しているようです

ほら、これを有効にするためにPRを作成しましたが、拒否されました。
私はこれがビルダーで起こっているのを見ていません。

最後の電話をかけたようです。 それでは、PRスレッド自体をかき混ぜます。

これは、CentOSで古いJDK 1.6パッケージをインストールするために必要です。これは、RPMが登録しようとするbinmft_miscが、-privilegedで実行せずに失敗するためです。

Dockerbuildは、それを使用してコンテナーを構築するための非スタテルです。

複製するには

Centos5.11から
yum intall -yjre-1.6.0_29-fcsを実行します

オプションのフラグとして、ビルドの特権コマンド部分が必要です。 アプリケーションの1つをPOCとしてdockerに移植しようとしていますが、適用されていないIPtables設定があり、ビルドが失敗するため、コンポーネントの1つで失敗します。 必要な変更を手動で行ってコミットすることはできますが、Dockerビルドの面白さは何ですか。 これはビルドの一部にすぎず、すでにメインリリースの一部であるため、簡単に移植できるはずです。

Dockerは、特権オプションが設定された中間コンテナーを簡単に実行できる必要があります。

@shubhamrajvanshi現在、「ビルダー」をデーモンから（およびクライアントに）移動しています。これにより、ビルドプロセスをさらにカスタマイズできるようになります（カスタムビルダーの実装を含む）。 おそらく「特権」ビルドを許可することを検討できますが、それはリファクタリング後に行うことができる決定です。 （https://github.com/docker/docker/blob/master/ROADMAP.md#122-builderを参照してください）

@shubhamrajvanshi正当な理由により、ビルドでiptablesに変更を

--privilegedでできることはほとんどなく、ビルドでも意味があります。

@thaJeztahありがとうございます。
@ cpuguy83イメージでiptables-persistentパッケージを使用している場合でも、そうなるでしょうか。

これにより、ルールがディスクに保存されますが、残念ながら、ルールを再ロードする必要があります。

_USER POLL_

_このディスカッションに変更があった場合に通知を受け取る最良の方法は、右上の[購読]ボタンをクリックすることです。_

以下にリストされている人々は、ランダムな+1であなたの有意義な議論に感謝しています：

@karelstriegel

CoreOS上のDockerでnVidiaのCUDAドライバーを使用できるようにするために、これも本当に必要です。 彼らが提供するインストーラーは、カーネルソースに対してカーネルモジュールを構築し、modprobeを使用してインストールします。 ある種の--privilegedオプションをビルドしないと、それを機能させる方法がわかりません。

デフォルトでビルド時に常に特権モードをサポートしないのはなぜですか？

+1
私はcentos7のDockerfileでmysqlコマンドを使用したいと思います。
もちろん、entrypoint.shを使用することもできますが、ビルドと実行の両方に-privilegedを使用できるとさらに便利です。

MySQLコマンドを実行するために--privilegedは必要ありません。

この問題は発生しないように思われるため、この問題を解決する必要があります（または発生するはずです）。
ビルドで特権を許可するということは、ビルダーがホスト上のものを変更できるようにすることを意味します。これにより、イメージがそのホスト（または同様の変更が加えられたホスト）でのみ機能するようになります。

ビルドで特権を許可するということは、ビルダーがホスト上のものを変更できるようにすることを意味します。これにより、イメージがそのホスト（または同様の変更が加えられたホスト）でのみ機能するようになります。

これはchrootユーザーの場合に当てはまりますか？

私はこのようなものなしでdpkg-depcheck -d ./configureを行う方法を見つけようとしています。

ビルド中（または--priviledgedなしで実行）に、以下のエラーが発生します-必要な権限や有効化する方法がわかりません。

dpkg-depcheck -d ./configure
strace: test_ptrace_setoptions_followfork: PTRACE_TRACEME doesn't work: Permission denied
strace: test_ptrace_setoptions_followfork: unexpected exit status 1
Running strace failed (command line:
strace -e trace=open,execve -f -q -o /tmp/depchJNii2o ./configure
devel<strong i="8">@98013910108c</strong>:~/src/cairo-1.14.2$ 

約3年と162のコメントを経て、私はそれを行うことにenufの興味を持っていると思います。 引用されたケースのほとんどに特権モードが必要ではないというコメントは、私自身でさえ真実です。 ただし、ローカル、一時的、探索的、および/または適切なビルドに役立つ可能性のあるものを禁止するために使用しないでください。 牛が調和を放屁するまで警告を発行し、コマンドラインの警告を印刷し、その使用を罵倒して非難しますが、人々に柔軟性を与えます。 移植性は必ずしもすべての人の主な関心事ではありません。

_USER POLL_

_更新の通知を受け取る最良の方法は、このページの_Subscribe_ボタンを使用することです。_

問題について「+1」または「私もこれもあります」というコメントは使用しないでください。 自動的に
スレッドを短くするために、これらのコメントを収集してください。

以下にリストされている人々は、+ 1のコメントを残すことによってこの問題に賛成しています：

@robeferre

+1

Dockerコンテナ内にNFSボリュームをマウントする必要があります。これまで、「-privileged = true」フラグがないとNFS共有を作成できませんでした。 私の意見では、特権コマンドを使用してイメージを作成するのが最善のケースです。 これはどのように可能ですか？

+1

Step 19 : RUN lxc-create -t ubuntu.sf -n percise -- -r precise -a i386 -b root
 ---> Running in 4c51b7cf0058
lxc_container: lxccontainer.c: create_run_template: 893 error unsharing mounts
lxc_container: lxccontainer.c: create_run_template: 1084 container creation template for percise failed
lxc_container: lxc_create.c: main: 274 Error creating container percise
The command '/bin/sh -c lxc-create -t ubuntu.sf -n percise -- -r precise -a i386 -b root' returned a non-zero code: 1

ビルド中にDockerのgentooシステムにgobject-introspectionをインストールしようとしていますが、次のエラーで失敗します：

• ISE：_do_ptrace：ptrace（PTRACE_TRACEME、...、0x0000000000000000、0x0000000000000000）：操作は許可されていません

コンテナに手動でインストールしようとすると同じ結果になりますが、特権モード（docker run --privileged）で起動されたコンテナから試してみるとうまく機能します。

glibcをインストールしようとしたときに同じ問題が発生します。

したがって、ビルド中に特権コマンドを実行する方法も必要です。

Dockerバージョン1.10.1を使用していますが、Glibcの問題は1.9では発生しません

バージョン1.10では、ネットワークが利用できないため、32ビットコンテナを構築できません。
--privilegedまたは--security- optseccomp：unconfined forBUILD-は本当に必要です。
またはDockerfileの対応するディレクティブ

私からの大きな+1

ビルド中に「mount」コマンドを使用できないのは、私にとって本当の問題です。
ビルド中にホストディレクトリをコンテナにマウントできないという制限を克服しようとしていたので、ホストにNFSサーバーをセットアップし、NFS共有をマウントしてみましたが、非特権モードのためにマウントできないことがわかりました。

私のユースケースでは、ビルドコンテキストにコピーせずにイメージにいくつかのものをインストールし、インストールする前に追加する必要があります。

選択肢がないままになっているような気がします。

thaJeztahは3月10日にこの問題を参照しました
1.10.2にアップグレードした後のLTTng動作のリグレッション＃20818クローズ

いいえ、閉じていません。1.11.0-0〜wilyを使用しており、32ビットコンテナでは、1.10.0以降、neworkingは機能していませんが、1.9.xは問題なく機能しました。
コンテナを起動するのに役立つのは-privilegedだけです。 しかし、私たちは新しく構築することはできません

このスレッドだけで2。5年間物乞いをしていて、この機能を実装するためのPRを提出しているにもかかわらず、多くの人が明らかに必要としているものが実装されていないことに驚いています。

@ctindelに同意しDockerから

@ctindelこれは、実装またはサポートする準備ができていないものです。 実装自体はかなり単純です（私はそれを自分で実装したので、議論することができました）、それは問題ではありません。

--privilegedは戦車であり、ビルド時に許可することは危険であり、イメージの移植性に大きく影響します。

ブライアン、

回避策がある場合は、それも私と共有してください。 私は...するだろう
感謝します。

ありがとう
Shubham Rajvanshi
669-300-8346

午後2時30分月、2016年5月2日には、ブライアン・ゴフの[email protected]は書きました：

@ctindelhttps ：//github.com/ctindelそれは私たちが準備ができていないものです
実装またはサポート。 実装自体はかなり単純です（私も
自分で実装したので、話し合うことができます）、それは問題ではありません。

--privilegedは戦車であり、ビルド時に許可することは危険であり、
画像の移植性に大きく影響します。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/docker/issues/1916#issuecomment -216369957

移植性への影響がわかりません。 ビルド時の特権操作は移植性にどのように影響しますか？ つまり、特権の有無にかかわらず、さまざまな方法で非ポータブルイメージを作成することは難しくありませんが、特権操作で作成されたイメージが必然的に非ポータブルであるという方法はありますか？

すべてのコンテナがポータブルでなければならないと思います。 一部のコンテナはコミュニティと共有するために作成され、一部は内部アプリケーションを展開するために作成される場合があります。

特権モードでの実行を必要とするアプリの移植性の問題は、アプリ自体にあります。

特権モードは、コードを変更せずにアプリを動作させるための最後の手段です。

特権モードの構築を必要とするイメージビルダーは、そのようなコンテナーも特権モードでの実行を必要とする可能性があることを理解していると思います。

移植性の問題が発生する可能性があるため、特権モードでの構築は推奨されないことを明確に文書化する必要があります。

Outlook Mobileから送信

午前2時53分PM -0700で月、2016年5月2日には、 "トレバー・ブラックウェル" < [email protected] [email protected] >書きました：

移植性への影響がわかりません。 ビルド時の特権操作は移植性にどのように影響しますか？ つまり、特権の有無にかかわらず、さまざまな方法で非ポータブルイメージを作成することは難しくありませんが、特権操作で作成されたイメージが必然的に非ポータブルであるという方法はありますか？

このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信するか、Gi tHubhttps：//github.com/docker/docker/issues/1916#issuecomment-216375159で表示してください

@tlbtlbtlb特権モードでは、ホストへのフルアクセスが提供されるためです。 たぶん私はshmmaxのような単純なものかもっと悪いものを設定しました。
私はこれらのことが1日目に起こることを保証します。

@ davidl-zendの「ポータブル」は、コミュニティと共有することを意味するものではありません。 これは、あるマシンから別のマシンに移動することを意味します。

@ cpuguy83他の人が指摘しているように、画像の移植性を損なう方法は他にもたくさんあります。 特権ビルドのプロセスがないために行っているのは、Dockerfileから部分的にビルドしてから手動でコンテナーを変更してコミットするか、Dockerfileから部分的にビルドして終了することにより、2段階のプロセスを強制することです。コンテナが最初に起動されたときの特権インストール。これは、時間のかかる作業を行っている場合、最初の起動が機能するまでに数分かかる可能性があることを意味します。

さまざまなフォーラムで見たコメントを考えると、今日存在するDockerの制限を回避するために、多くの人々がすでにこれを正確に実行していることは間違いありません。

他の数十の方法で画像の移植性が損なわれるアーキテクチャができたら、この特定の風車に対して傾斜することにはどのような点がありますか？

明らかに、dockerhubやtravis-ciでイメージをビルドすることはできなくなりますが、特権モードでビルドする必要がある人は、とにかくそれを理解するでしょう。

@ctindel画像の移植性が壊れている例をいくつか見てみたい

コンテナの最初の起動時にこの種のことを行うことは、_正確に_正しい方法です。
これはランタイム構成であり、イメージに含めるべきではありません。

@ cpuguy83誰かがDockerfileから部分的なビルドを実行し、特権モードでコンテナーを起動し、さらに変更を加えてから、docker commitを実行できるという事実について議論していますか？ これは、特権モードでビルドを実行する場合とどのように異なりますか？ それが今日他の人がしていることだからです。

私は辛抱強くなるつもりはありません。これは、人々が厄介な方法で回避しているプラ​​ットフォームに対する厳しい制限であると言っているだけです。

たとえば、システムに特定の機能がない限り、正しくインストールできないサードパーティのDebianパッケージ（およびおそらくRPM）があります。 Debianパッケージのインストールは「ランタイム構成」ではなく、インストールプロセスの奇妙な部分です。

@ctindelこれについてはまったく議論していません。 違いは、動作をサポートすることです。 違いがなければ、この議論はありません。

私にとって、私は同意する大人であり、多数のノード間で

@ cpuguy83人々が他の方法で回避しているこのオプションを提供しないことによって正確に何が得られるかは、私にはまだ非常に不明確です（そしてこのスレッドの他の人もそう思います）。 とにかくコミットオプションが追加された瞬間に、あなたが主張しているようなアーキテクチャの純粋さ（私にはそれについてのより良い言葉はありません）はなくなったので、それが経由で行われるかどうかにどのような違いがあるのか​​本当にわかりません特権ビルドを使用したDockerfile、または特権コンテナー内のdockercommitを介したDockerfile。

片道が人々にとっておかしなPITAであり、Dockerfileを使用して構築する現在のメカニズムへの片道スロットが非常にうまく機能していることを除いて。

また、あなたは私の質問に答えませんでした。 サードパーティのDebianパッケージ（またはパックスタック）の単純なインストールを「ランタイム構成」と見なすのはなぜですか？

@ctindelポータビリティ。 何かができるからといって、それがサポートされているわけではなく、それをbuildに含めると、誰もが簡単に実行できるようになり、サポートされていることを意味します。
ホスト間でイメージが機能しないという問題が殺到します...これは基本的にDockerの理由全体を打ち負かします。

パッケージをインストールするために--privilegedが必要な場合は、パッケージで対処する必要があります。 インストールには--privilegedは必要ありません...本当に必要な場合は、インストール自体が移植性がないことを示しています（ホスト上で変更する必要があります）... dockerが--privilegedないコンテナーで実行可能であることを確認してください（実行可能であることに注意してください。--privilegedがなくても問題なくインストールできます）。

ただし、docker commitを介して実行できるようにすることは、それもサポートされていることを意味します。

理解できません。サポートされていない画像について誰かが個人的に不満を言うのではないかと心配しているため、この製品の制限を回避するために多くの人が働いていますか？

パッケージをインストールする行為（ここでは構成についても話していません）が「ランタイム構成」の行為である理由についての私の質問にはまだ答えていません。 「携帯性」と言っても意味がありません。

Dockerに固有のx86_64はありますか？ 最終的に、特定のCPUアーキテクチャ用に構築されたDockerイメージはありませんか？ それはまたそれらを携帯不可能にしませんか？ とにかく、他の多くの変数に関係なく、いつでも任意のDockerイメージを取得して、世界中の任意のDockerホストで実行できるというこの考え全体は不可能に思えるので、プッシュする必要性が非常に高いことはわかりません。人々が求めているこの特定の機能に戻ります。

ところで、ここであなたの返事と継続的な関与に感謝します。 問題のスレッドが無視される他の多くのgithubプロジェクト！

docker run --privilegedとdocker commitを使用して、これを回避する人々についてのポイントに同意します。 私はこれまでに2つの会社のためにそのような解決策を作りました。 人々はそのようなイメージを作ります、そしてそれをすることが何か恐ろしい、恐ろしいことであるかのように振る舞うことに意味はありません。

地獄、 --privileged構築されたコンテナをサポートすることを非常に恐れている場合は、ドキュメントにそのように明確に記載して、人々が自分の責任でそれを行っていることを完全に認識できるようにしてください。 今のところマイナスの影響は見ていませんが。 しかし、ここでも、異なるディストリビューションでコンテナーを実行しようとはしていません。

@PerilousApricot実際に--privilegedを追加するだけがこれを行う正しい方法であるとは考えていません。 人々が特定のビルドの問題を提起したことを私が知っているすべてのケースは、ビルドを行うために実際にはホストマシンへのルートアクセスを実際に必要としないため、一般的に修正できます。

@justincormack initスクリプトがtmpfsファイルシステムをマウントする必要がある独自のサービスを開始するサードパーティパッケージ（つまり、変更できない）の解決策は何ですか？ 今のところ、-privilegedを無視しても、ビルド中に--cap-addまたは--security-opt apparmor： unconfinedを実行する方法はありません（私は思いませんか？）

@ctindelインストール時にtmpfsをマウントしようとしてはいけません。 実行時にtmpfsが必要な場合は素晴らしいですが、インストール時には間違いなく正しくありません。

@ cpuguy83商用のサードパーティからのものであるため、変更できないものにアーキテクチャと実装の哲学を課しています。 すべてが「アップストリーム」で修正されるわけではありません。新しいバージョンの.debまたは.rpmが修正されたとしても、Dockerイメージで必要になる可能性がある古いバージョンに戻って再投稿するわけではありません。

これがこの議論全体のポイントです。「間違っている」人々からのサポートの要求に関する哲学的な懸念のために、Dockerの使用をはるかに困難にする恣意的な制限を課しています。

これは、オペレーティングシステムでは、プロセススケジューリングクラスを変更できないようにする必要があると言っているようなものです。間違って変更すると、優先順位が逆転する可能性があるためです。 または、間違って使用すると親指を打つ可能性があるため、誰もハンマーを作らないでください。

何度も言われているように、dockerはcommitコマンドを介してこれをすでにサポートしていますが、ユーザーにとってはさらに苦痛です。 この機能を望まない人は使用しないでしょうし、制限を理解して使用したい同意した大人は目を大きく開いて使用することができます。

@ctindelいや、半径50 kmのすべての人を殺す可能性があるため、この核爆弾を処理することはできません。

インストール中にtmpfsをロードする必要があるのは、このパッケージについて何ですか？ インストールとは、文字通り、あるアーカイブ形式からrootfsにファイルを抽出することです。

何でも変更できます。
ビルド時に特権を有効にするよりも、インストール時にtmpfsをマウントしないようにアップストリームで行う方が、はるかに簡単で安全な変更です。

Dockerは、ワークロードの移植性に関するものです。 ビルド時に特権を有効にする（または追加の特権、またはセキュリティプロファイルを微調整するなど）ことは、これを根本的に破り、今日私たちが受け入れることができるものではありません。

commitとbuildは2つのまったく異なるものであり、ある方法で何かを実行できるからといって、他のすべての方法でも実行できるようにする必要があるわけではありません。

FROM python

ENV PACKSTACK_VERSION 7.0.1
RUN cd /opt && git clone https://github.com/openstack/packstack.git \
  && cd packstack \
  && git checkout $PACKSTACK_VERSION \
  && rm -rf .git \
  && python setup.py install

特権は必要ありません。

収益性の教会。
いつの日か「強制的な」移植性はこのプロジェクトを殺すでしょう-それはすでにそれをやっています。
とらえどころのない移植性のために非常に多くの機能が拒否されており、それのためにあまり進歩が見られません.....
ある日、誰かがプロジェクトをフォークし、移植性をオプションにします。 夢...夢....アーメン。

それを2つのケースに分解すると：

1. パフォーマンスのためにtmpfsをマウントするなど、特権操作を軽率に使用するインストーラー。 このようなインストーラーは簡単に修正できます（ただし、近い将来には修正されない可能性があります）。

この場合、Dockerが動作の悪いインストーラーをプッシュバックすることは有効な哲学です。 ほとんどのインストーラーには、Dockerfileを少し長くするような回避策があります。

1. GPUドライバー用のカーネルモジュールのインストールなど、基本的に特権操作に依存するインストーラー。 これらも基本的にポータブルではありません。 たとえば、Mac用のdocker-machineでは動作しません。

この場合、Dockerエクスペリエンスはとにかく壊れています。 Macでdocker-machineを使用できません。たとえば、互換性のあるターゲットホストマシンでのみイメージをビルドできます。 私の使用例は、ホストOS（CoreOS）にnVidia GPUドライバーをインストールすることでしたが、ホストOSに直接インストールすることはできませんでした。

だから、私はサポートしないことの美徳を見に来たと思います-どちらの場合も特権があります。 私が考えを変えたのは、最初にコードをUbuntuボックスにプッシュしてそこでビルドするのではなく、docker-machineを使用してラップトップでイメージをビルドするという便利さだと思います。

@tlbtlbtlbあなたが何の「美徳」を指しているのかわかりません。 取るに足らないものではないものを考えてみてください。ただし、ある環境では実行され、別の環境では実行されないDockerイメージが大量にあります。 たとえば、ホストボリュームをlinux-> linuxからmongodbコンテナにマウントできます。これは、mmapv1ストレージドライバが正常に機能するためですが、macosxディレクトリをvirtualbox経由でラップトップのmongodbコンテナに渡すことはできません。その場合、mmapのものは正しく機能しません。

これはビルドに関しては問題ではないことはわかっていますが、Dockerイメージは「ポータブル」であり、「どこでも実行」できるという考えは、現時点ではまったく意味がありません。 彼らがどこでも走ることができない場合、彼らが「どこでも建てることができる」と言うことの美徳は何ですか？

重要なのは、mongodbイメージがどこでも機能するということです。 無効なランタイム構成を提供することは別の獣です。

Dockerには、ポータブル構成と非ポータブル構成の非常に具体的で腸の分離があります。

これはどう ？
コンテナ内の実際のIPをnginx構成チェックパスに渡す必要があります。

これは私のDockerfileです：

FROM ubuntu:14.04.4

RUN apt-get update
RUN apt-get install -y software-properties-common
RUN add-apt-repository ppa:nginx/stable
RUN apt-get update
RUN apt-get install -y nginx-full vim
RUN ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up
RUN ifconfig lo:1 192.168.168.57 netmask 255.255.255.0 up
RUN ifconfig lo:2 192.168.168.58 netmask 255.255.255.0 up

ADD . /etc/nginx

➜  nginx git:(ha-node-01) ✗ docker build -t nginx4test .
Sending build context to Docker daemon 976.4 kB
Step 1 : FROM ubuntu:14.04.4
 ---> 90d5884b1ee0
Step 2 : RUN apt-get update
 ---> Using cache
 ---> eea42cb6135d
Step 3 : RUN apt-get install -y software-properties-common
 ---> Using cache
 ---> 9db86ab17850
Step 4 : RUN add-apt-repository ppa:nginx/stable
 ---> Using cache
 ---> 5ed2266a93a9
Step 5 : RUN apt-get update
 ---> Using cache
 ---> 09fcfdc1fed3
Step 6 : RUN apt-get install -y nginx-full vim
 ---> Using cache
 ---> cc0c1662e009
Step 7 : RUN ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up
 ---> Running in 5d962ec4e35d
SIOCSIFADDR: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
SIOCSIFNETMASK: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
The command '/bin/sh -c ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up' returned a non-zero code: 255

特権オプションを使用してコンテナを実行すると、IPをループバックインターフェイスに設定できます。 ただし、追加するスクリプトはもう1つあります。

@私は20行かそこらについて持っているiptableエントリ私はしたいと思いますRUN私にDockderfileが、私は必要とすることはできませんので、 --cap-add=NET_ADMIN 。 これらのコマンドは、コンテナーを実行しているユーザーや、コンテナーを実行しているマシン（コンテナーが内部アプリを実行している）に関係なく実行する必要があります。 あなたが上で議論したことに基づいて、どこで/どのように私がそれをすることを提案しますか？

@MatthewHerbst残念ながら、iptablesルールはイメージで保持されない/保持されません。

@ cpuguy83 centos:6イメージを使用しており、実行/sbin/service iptables saveを実行して、ルールをファイルシステムに永続化できます。 それらは、 iptables-persistentパッケージを介したUbuntuやその他の機能と同様の機能だと思います。

そのファイルのiptablesルールを生成するだけで、必要はありません。
実際にそれらを適用します。 コンテナが実行されているネットワークの状況は、
非常に異なるため、実行時にルールを適用する必要があります（その場合は、
ホストがそれらを生成する方が良いかもしれません）。

2016年5月16日16:03、「MatthewHerbst」 [email protected]は次のように書いています。

@ cpuguy83私はCentOSを使用しており、run / sbin / service iptables
ルールをファイルシステムに永続化します。 私は彼らが似ていると信じています
iptables-persistentパッケージを介したUbuntuなどの機能。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください

@justincormackは、なぜ私がそれを考えなかったのか

docker serviceを使用するときに、特権を必要とするコマンドをどのように実行することになっていますか？ いくつかのマシンでホスト名を設定する必要がありますが、残念ながらこれには特権が必要です。

@nostreborは、この未解決の問題とはほとんど関係がありません。
サービスを1対1でコピーするのではなく、サービスに必要なオプションを評価しています。 特権モードは、サービスの1.12ではおそらくありません。

インストール用に何かをコンパイルするDockerビルドを試していますが、CVMFSネットワークファイルシステムに存在するライブラリに対してコンパイルする必要があります。 もちろん、-privilegedを実行せずにCVMFSをマウントすることはできないため、Dockerfileを使用してマウントすることはできません。

@ cpuguy83 @tlbtlbtlbこれは、基本的に特権アクションに依存する「インストーラー」の場合です。 しかし、それは私が「軽薄な使用」と呼ぶものではなく、ネットワークファイルシステム上の共有ライブラリにアクセスする必要があるだけです。 それでも、この場合のインストールは、単にアーカイブからファイルを抽出することではありません。

ネットワークファイルシステムのマウントが移植性の問題であることがわかりません。 （すべてのターゲット環境がこのファイルシステムにアクセスできます。ネットワークファイルシステム上のバイナリコードにもリンクする必要がある他のコードをビルドするため、これらの環境にアクセスする必要があります。）

別のアプローチを試す必要がありますか？ CVMFSをホストにマウントし、そのディレクトリをコンテナなどと共有する必要がありますか？ このイメージを作成するためだけに外部ビルドシステムをセットアップする必要はありません。ベースとなるイメージには、そのジョブを実行するビルドシステム全体がすでに含まれています。 CVMFSをマウントできる必要があります。

Dockerfileを使用してこれを行うことに興奮しましたが、 docker run --privilegedを使用するスクリプトを使用するか、dockerの代わりに別のスクリプトを使用する必要があるようです。 特権アクセスを持たないコンテナにファイルシステムをマウントする方法はありますか？

スクリプト内に特権コマンドを配置/エコーし、CMD命令を使用してコンテナーのエントリポイントでスクリプトを実行することで回避策を実行したので、そのようなイメージを作成した後、コンテナーを特権モードで実行するだけですべてが機能します。

@ drstapletron 、CERN cvmfsのドキュメントによると、今のところ2つのオプションがあります。ホストからコンテナにcvmfsをマウントするか、特権コンテナ内にcvmfsをインストールします。

秒の場合、cmsswの人のためにdocker-fileをここに書きました：
https://github.com/iahmad-khan/system-admin/blob/master/cvmfs-inside-docker.Dockerfile

したがって、このファイルを使用すると、イメージをビルドして（または、cmssw dockerhubから取得することもできます）、Pモードで実行すると、すべてがコンテナー内に既に存在します（ls / cvmfs / *）

これはこの問題に関するフィードバックのかなり長いリストであるため、これが上記でカバーされているかどうかはわかりません。 私も--privilegedビルドコマンドが欲しいです。 私の現在のユースケースは、gentooステージ3でgoebuildをビルドする際に遭遇した問題を回避することです。 コンテナを使用しない場合、gentooハンドブックの現在の手順により、 'umount -l / mnt / gentoo / dev {/ shm、pts、} && umount -l / mnt / gentoo / { systemdで起動したシステムからのproc、sys} '... stage3ビルドをdockerコンテナーに移動すると、ビルドにptraceまたはその他の制限された機能が必要になるまで、すべてが正常に機能します...これはgo-1.7.1です。 ebuildが必要なようです。

今のところ、docker runコマンド内でビルドを実行し、コミットしてから続行していますが、手動の手順を回避するために、dockerbuildコマンド自体でptraceを有効にすることをお勧めします。

この機能も欲しいです。 ビルド環境を作成したいのですが、カーネルモジュールが必要で、ビルド時にmodprobeが連携しません。 これに対する回避策はありますか？

具体的には：

modprobe vcan && \
ip link add type vcan && \
ifconfig vcan0 up

完全に合理的なユースケースのようです。

@seltzy docker誰かがあなたのユースケースの合理性を認めるのを待って、息を止めないことをお勧めします。

アーキテクチャと機能の包含に関しては、それらは非常に手間がかかり、実用的で、よそよそしく、ロードマップに適合しないすべてのユースケースを無視する傾向があります。

私たち一般の人々は理解する必要があります。 dockerチームは、自分たちの（おそらくビジネス顧客や自己奉仕）ニーズを促進するアーキテクチャの決定を下します。これらの決定は、私たち（パブリックエンドユーザー）の非常に骨の折れる細工と重複することはめったにありません。ここで提出する問題。

もちろん、この方法でエンジニアリングリソースを自由に割り当てることができます。
しかし、それは、会社が「ユーザーのニーズを真剣に受け止めている」と説明された場合に想像力をかき立てるような実績を提供します。

@tamskyあなたはそれを釘付けにしました！

@tamskyプロジェクトがあなたが明らかに望んでいる機能を受け入れていないので、なぜあなたがそう思うのか理解できます。

これは、いかなる種類のビジネス上の決定とも関係がないことを保証できます。 実際のところ、ビルド時に--privilegedを使用すると、移植性のないイメージになります。
ビルド環境のmodprobeようなものは役に立たず、2つのビルドでまったく異なる結果が生じる可能性さえあります。

私自身、ビルドに--privilegedを実装しました。 これはエンジニアリングの問題ではなく、実際に実装するのは非常に簡単です。 問題はそれをサポートしていることです。
上級ユーザーの場合、特権サポートを含めることができる既存のAPIを使用して、既存のコードを再利用するカスタムビルダーを実装できます。

とはいえ、この問題はまだ未解決です。 人々が聞いているからです。

よろしくお願いします。

@ cpuguy83説明ありがとうございます。 移植性の問題だとは思いませんでした。 これに対する私の欲求は誤解によって煽られていると思います。

特権ビルドをしたいという誘惑に直面したときに取るべき一般的な哲学的アプローチは何ですか？

@seltzyは、ユースケースがこの機能の必要性の合理的な例ではないことを確信していない

@ cpuguy83ユースケースについての返信をまだ必要があるネットワークファイルシステムを介して分散されています。 これには、コンテナを特権モードで実行する必要があります。 ソフトウェア配布にネットワークファイルシステムを使用するという私の機関の決定は、素粒子物理学にとって珍しいことではありません。 ビルド時に--privilegedを使用すると、移植性のないイメージが作成されるとのことですが、これは私のユースケースとはまったく関係ありません。 私たちの開発モデルは、ネットワークファイルシステムを使用しているために（本当に？）失う可能性のある移植性をすでに放棄しています。 開発マシンをマウントする必要があります。

@ cpuguy83PSあなたはカスタムビルダーについて言及しました。 これに関する情報はどこにありますか？ ありがとう！

コンテナの移植性に関するこの全体的な議論は、とにかく巨大な赤いニシンです。 ステージ1のイメージを作成し、特権モードでコンテナーを起動し、必要なことをすべて実行してから、docker commitを使用してそのコンテナーから最終的なイメージを作成することで、すでに同じことを実現できます。

Dockerコミットオプションを追加すると、とにかくイメージの移植性の概念が外に出てしまうため、1つではなく3つのステップでこれを実行するように強制しても何も得られず、特権ビルドオプションを実際に使用できる人々を困らせるだけです。

@drstapletronファイルシステムのマウントは、必ずしも移植性を損なう可能性があるものではありません（誰かがイメージにマウントされることを期待していない限り）。
ここでの問題は、ファイルシステムをマウントする機能があるということは、他の厄介なことをたくさん実行できることも意味します。

@ctindelはい、作成したコンテナでやりたいことは何でもできます。 docker build 、

ポータブル画像は赤いニシンではありません。 ワークロードの移植性は、Dockerの主要な設計目標です。 私たちの主要な指令、いわば。

@seltzyほとんどの場合、昇格された特権は何らかの方法でホストを変更するために使用されるため、追加の特権を必要とするほとんどのものは実行時に属します。
そうは言っても、ビルド時にいくつかのことが必要であることは確かに理解できます（上記のnfsマウントなど）...しかし、NFSの場合でも、手動でイメージをビルドする場合（ docker build ）、私はコンテナに--privilegedや追加の機能をまったく提供せず、代わりにnfsエクスポートをボリュームとしてマウントします。

@drstapletron mountは--privileged必要とせず、より制限された機能セットのみを必要とし、ほとんどの人が行うホストへの完全なルートアクセスを提供するため、完全な特権モードよりも早く発生する可能性が高くなりますほしくない。 （まだセキュリティの問題がありますが、より管理しやすくなっています）。

したがって、完全に移植可能で、ホストを変更しないユースケースがあります。 それはオープンソースでさえあり、あなたはそれをここで見ることができ

基本的に、ポータブルDockerコンテナでMockを実行して、カスタマイズされたCentOSISOイメージを構築したいと思います。 モックは、知らない人のために、コンテナ化されたRPMビルダーです。 問題は、コンテナを使用しているため、 --privilegedまたは--cap-addです。 理想的には、 docker buildは関数のように機能し、いくつかの引数を取り、その最終結果を返すと思います。 しかし、これらのフラグがなければ、私はそれを行うことができません。

こっちも一緒 ！ Docker内でモックを使用することは、そのために悪夢です:(

Sending build context to Docker daemon 9.728 kB
Step 1 : FROM centos
 ---> 980e0e4c79ec
Step 2 : MAINTAINER Gregory Boddin
 ---> Using cache
 ---> 93e709c87f25
Step 3 : RUN yum install -y spectool mock
 ---> Using cache
 ---> 7006ef8d0276
Step 4 : RUN useradd mock -g mock
 ---> Using cache
 ---> bfb931c56d89
Step 5 : ADD *.cfg /etc/mock/
 ---> Using cache
 ---> 15521d2822b1
Step 6 : RUN su mock -c"/usr/bin/mock -r edge-5-x86_64 --init"
 ---> Running in 542a742b6017
INFO: mock.py version 1.2.17 starting (python version = 2.7.5)...
Start: init plugins
INFO: selinux disabled
Finish: init plugins
Start: run
ERROR: Namespace unshare failed.

@ cpuguy83は書いた：

実際のところ、ビルド時に特権が与えられると、移植性のないイメージになります。

広範囲にわたる移植性を必要としない人のために--privilegedを許可しないのはなぜですか？
公式ドキュメントの簡単なメモは、妥当な妥協案です（たとえば、_警告： --privilegeをbuildコマンドに渡すと、イメージの移植性が低下する可能性があります！_）。 これにより、ほぼすべての人の要件が解決されます。 一部のユーザーは移植性を必要とせず、一部のユーザーは必要です。警告はすべての人のニーズを満たすのに十分です。

build --privilegedため、現在のユースケースが大幅に複雑になっていると確信しています。

--non-portableと呼ぶことができます。 Dockerのデプロイメント部分はまだ使用していませんが、分離+オーバーレイファイルシステムのものは、それがなくても非常に便利です。

インストールするために特権コンテナを必要とするいくつかのプロプライエタリソフトウェアを使用する必要があります。 これについて私にできることは何もありません。 ビルド、実行、コミットの3段階のプロセスを実行する必要があります。

コンテナの移植性は、私や私のビジネスにとって何の意味もありません。実際、大多数のビジネスにとっては何の意味もありません。 重要なのは、維持するソフトウェアを減らしたいということです。したがって、この問題で使いやすさよりも移植性を選択することは、Dockerにとって有害だと思います。

このための+ 1、setfaclを使用するビルドプロセスでは、これはビルド中に失敗し、サービスはコンテナで開始できません。 エンドユーザーとして制限されるべきではないと思います。必要な場合にのみ--priviledgeオプションを使用し、デフォルトは無効になっています。

このために+1。 ビルドプロセスでは、/ procと/ devをマウントする必要があります。 理想的には、dockerfileの一部としてマウントステップを実行できる必要があります。

@ samsun387ビルドプロセスでこれが必要なのはなぜですか？

@skshandilya setfaclは移植性がなく、aclを画像に永続化できるとしたら驚きます。

@robhaswell 「特権コンテナが必要」はあまり役に立ちません。 インストール時に実際に何が使用されていますか？

+1。 モックinitにはこれが必要です。
ほとんど全体の問題を読んでください。 なぜ人々が「なぜこれが必要なのか」と3年連続で尋ね続ける理由を理解しないでください。

@Betriebsrat 「Xにはこれが必要」というのはそれほど
「X」は何をしているのですか？ ビルドフェーズで「X」がこれを必要とするのはなぜですか？

たとえば、 /procと/devをマウントする機能を備えた上記のケースは、実際にはビルドフェーズに適した場所ではなく、イメージがそのようなホストに関連付けられているようにさえ見えます。ケース。

「特権」も戦車です。 それは絶対にすべてを開き、すべてのセキュリティ機能を無効にし、通常は読み取り専用の場所への書き込みアクセスを提供します...おそらく誰かが非常に特定のことを行うことができる必要があるだけです。

これらの質問は、実際のユースケースとそのようなケースをどのように満たすことができるかを知るために行われます。

ちなみに、私が「セキュリティ機能」と言うとき、私は2つのことを意味します：

1. ハッキングを防ぐための事柄
2. アプリケーションの懸念をホストの懸念から分離します（つまり、イメージビルドは、イメージをその上に構築されたホストに結び付けてはなりません）。

私のは21051によって解決されたようです、私は今のところ外出しています:)

@shykesは2013年11月28日に@https： //github.com/docker/docker/pull/2839#issuecomment -29481246 ::

申し訳ありませんが、現在の設計では「1ソース、1ビルド」を適用するため、ソースディレクトリ以外のdockerビルドへの引数は許可されていません。

一部のビルドは、特権操作が必要なため、現在実行できないという事実を理解しています。 これを適切に処理するには、1）Dockerfileが特権的な方法でビルドする必要があることを表現できるようにし、2）Dockerがビルドを一時停止できるようにする認証/トラスシステムを実装し、ユーザーにリスクを適切に警告する必要があります。 Dockerfileの出所と信頼性に関する情報を公開し、ビルドを許可または拒否するユーザーの決定を収集します。

@ cpuguy83 、「1ソース、1ビルド」の強制から設計が変更されましたか？
Dockerプロジェクトはその設計を変更し、このコミュニティが要求する機能を許可しますか？

上記のShykesのコメントは、これを処理するために「必要になる可能性がある」ことを詳しく説明しているようです。 同時に、使用されている言語（「可能性がある」）は、この設計変更を拒否する追加の理由を考え出すための多くの余地をDockerプロジェクトに提供しているように見えます。

NEEDS_PRIVILEGED宣言を追加することは理にかなっていますが、ビルドの一時停止に関するこれらすべてのことはありますか？ エラーで失敗し、本当に特権ビルドを許可したい場合は、オペレーターに--privilegedオプションを渡させます。

@ cpuguy83重要なのは、ビルドで特権モードが必要になるのは、通常、それを使用することのリスクを完全に理解しているパワーユーザーです。 そして、それらのほとんどはそれを受け入れ、それを必要とするステップのビルドの一部としてdocker commitを使用するだけでこれを回避します。

ビルドで特権モードを使用することを人々が妨げることは決してありません。単にそれを行うのが面倒になっているだけです。

あなたの目標がそれをするのを面倒にすることであるならば、それを何年も何年も続けるのではなく、ただそのようにはっきりと言って、この問題を閉じてください。

「煩わしいので修正しません」と言って、この問題を閉じます。

/スレッド

@ cpuguy83 、私の理解では、Mockはchroot / container環境を作成するときに、 unshare(2)とCLONE_NEWNSフラグ（場合によっては他のフラグ）を使用します。 これには、少なくともCAP_SYS_ADMINです。

「X」は何をしているのですか？ ビルドフェーズで「X」がこれを必要とするのはなぜですか？

私たちのユースケースでは、わかりません。 それは私たちが変えることができないいくつかの所有物のがらくたです。 重要なのは、私たちのビジネスは、「セキュリティ」（このコンテキストでは）や移植性、またはリストされている懸念事項のいずれも気にしないということです。 このいまいましいがらくたをコンテナに入れて、何か価値のあることをすることに移りたいだけです。

@PonderingGrowerが言うように、とにかくそれを行うつもりです、それは私たちがそれをしている間にどれだけの時間を無駄にするかという問題です。

ビルドで特権モードが必要になる人は、通常、それを使用することのリスクを完全に理解しているパワーユーザーです。

私はその仮定に強く反対します。 全体として、 --privilegedを使用するユーザーは、「問題が修正されたと誰かが書いたため」、 chmod -r 777を盲目的に実行するユーザーと同じカテゴリです。

私たちのユースケースでは、わかりません。 それは私たちが変えることができないいくつかの所有物のがらくたです。 重要なのは、私たちのビジネスは、「セキュリティ」（このコンテキストでは）や移植性、またはリストされている懸念事項のいずれも気にしないということです。

ここでの「このコンテキスト」とは、ホスト上で「独自のがらくた」ルートアクセスを許可することを意味します。

@thaJeztah問題ありません。 これは、私たちが購入してサポートを支払っているソフトウェアです。 コンテナを使用していなかった場合でも、インストールするにはrootが必要です。

ビルド中にdindを使用して、ビルド中のコンテナー内にいくつかのコンテナーを事前構成するために、この機能が必要です。

ここで3年間何について話し合っていますか？

docker runは、 --cap-add 、 --cap-dropなどのオプションがあります。 したがって、 Dockerfile RUNコマンドは、同じオプションを使用したいと考えています。 したがって、 Dockerfileは、親マシンに要求を送信し、いくつかの特権を追加/削除するように要求します。

親マシンは、これらの要求で必要なことを実行できます。 シェルをインタラクティブにしたり、GUI確認ダイアログを作成したりできます。なぜこの問題でこれらのリクエストの解決について話し合っているのですか？

かなりの数のDockerユーザーが、ビルドコマンドで--cap-addまたは--privilegedを実行して、実行コマンドにあるものを模倣する機能を望んでいます。

そのため、このチケットは3年間オープンしており、メンテナはこの特定のインスタンスでユーザーが望むものを提供することに関心がないにもかかわらず、人々は絶えずチャイムを鳴らしています。

@ctindelこれは間違いなくこの問題の問題です。 docker build --cap-addとRUN --cap-add間にギャップがあります。

子マシンからの特権要求をdocker build --cap-add=caps_arrayだけで解決したい人もいます。 それは何ですか？ これはただ： caps_array.include? requested_capです。

pre_requested_caps.include? requested_capが欲しい人もいます。 stdout << requested_cap, stdin.gets == 'y'が欲しい人もいます。 gui_confirm requested_capが欲しい人もいます。 間違いなくUAC_fullscreen_dialog requested_cap欲しい人もいます。

requested_capの解決方法はユーザーの好みに依存し、この質問は決して行われないと思います。

しかし、 RUN --cap-addは人々の好みとは何の関係もありません。 私たちは何をぐずぐずしているんですか？

@ andrew-aladevあなたの投稿が何を言っているのかよくわかりません。 重要なのは、サードパーティのソフトウェア（RPM、DEBなど）が管理されておらず、「Dockerビルド」時にイメージにインストールする必要があり、正しくインストールするには追加の機能が必要なことです。 これらはサードパーティのRPMであるため、インストールフェーズで特権を増やす必要があることを解決する方法はありません。

彼らは、これらの機能が強化されたコンテナーを実行し、ソフトウェアをインストールしてから、そのコンテナーからイメージを作成することで、この問題を回避しています。 これは苦痛であり、同じ目的を回路的に達成できるため、ビルド時にキャップの追加を禁止する機能的な理由がないことを明確に示しています。

@ctindel私の英語はあまり上手ではありません、ごめんなさい。

知っている。 glibcを出現させようとしましたが、 ptrace not permitted受け取りました。

dockerは、それ自体で機能を増減したコンテナーを実行できます。 RUNでコマンドDockerfileサポートする必要があります--cap-add 、 --cap-dropなど、

DockerfileにRUN --cap-add=SYS_PTRACE -- emerge -v1 glibcがあると想像してみましょう。 それはどのように機能しますか？

1. 子マシンは親にリクエストを送信し、 SYS_PTRACE要求します。
2. 親は拡張機能を許可します。
3. 親は、SYS_PTRACEを許可して新しいコンテナーを作成します。

この問題の誰も実際にそれについて議論していないようです。 人々はこれらの機能を許可する方法について議論しているだけです。

@thaJeztahは言った

全体として、-privilegedを使用するユーザーは、chmod -r777を盲目的に実行するユーザーと同じカテゴリです。

この男性は、 log :info, requested_cap; return privileged?だけでなく、必要な機能を検証するためのより柔軟な方法を望んでいます。

@ctindelあなたが言った

NEEDS_PRIVILEGED宣言を追加することは理にかなっていますが、ビルドの一時停止に関するこれらすべてのことはありますか？ エラーで失敗し、本当に特権ビルドを許可したい場合は、オペレーターに--privilegedオプションを渡させます。

シェルをインタラクティブにしたい。 stdout << requested_cap, stdin.gets == 'y'です。 これは、必要な機能を検証するもう1つの方法です。

@ cpuguy83は言った

誰かがおそらく非常に特定のことをすることができる必要があります...ハッキングを防ぐためのこと。

この男はdocker build --cap-add=caps_array caps_array.include? requested_cap望んでいます。 これは、必要な機能を検証するもう1つの方法です。

理由：求めています私はRUNでDockerfileまだのはサポートしていません--cap-add 、 --cap-drop 、等？ 誰もそれについて議論しません。 3年が経ちました！

@ andrew-aladev Builderがメインエンジンから書き換え/リファクタリング/デカップリングされるまで、dockerfile構文がフリーズすることが明らかになっているため、この構文については誰も主張していないと思います。 https://github.com/docker/docker/issues/29719#issuecomment -269342554

より具体的には、問題のタイトルとOPは--privilegedbuildを要求しています

これはFonzieの強打を取得します： 。

buildステップでstraceを実行できると、非常に役立ちます。
現在、私はデバッグする必要があるすべてのものをrunステップに移動することでこれを回避しています-理想的ではありません。

buildステップではなくrun機能する理由を誰かが知っていますか？ つまり、歴史的な理由。
多くの許可や設定なしで機能するstrace代替手段はありますか？

これに対する提案された解決策/回避策があります
https://github.com/docker/docker/issues/6800#issuecomment -50494871：

Dockerビルドに問題がある場合は、「ビルダーコンテナー」を使用できます。
docker run --cap-add [...] mybuilder | docker build -t myimage -

誰か（おそらく@tiborvass）がこれについて詳しく説明できますか？ ここでmybuilderはどのようなものですか？
いくつかのENTRYPOINTを含む画像名？ または、 [...]の画像部分であり、 mybuilderは参照します
シェルスクリプトに？ そして、 docker runにcontext.tar.gzをdocker build -に渡すように説得するにはどうすればよいですか？
それが本当にここで起こっていることなら。 よろしくお願いします、Steffen

@sneumann mybuilderは画像名であり、実際にはCMDまたはENTRYPOINTがあります。 その回避策が機能するための契約は、 mybuilderがコンテナ内からコンテキストをtar 、それをstdoutに移動させる必要があるということです。 渡され、そのdocker buildのSTDIN、シェルパイプのおかげで|とのコンテキストパスのでコンテキストであると考えられるdocker build -t myimage -ある- 。

コードを見ると少し奇妙ですが、このオプションはbuildコマンドで使用できるようです。

• run ：ここでのcontainerはrun意味すると思います-https：//github.com/docker/docker/blob/bb0a532fc21cb6b9390fb7e5eb0054bdc8045bbc/cli/command/container/opts.go ＃L485。
• build ： https ：

もっと手がかりになっている人は、なぜそれが適用されていないのか分かりますか？

@mbana --security-optは、「credentialspec」をサポートするネイティブWindowsコンテナー用ですhttps://github.com/docker/docker/pull/23389

これを変更して永続化して、将来のbuild ptraceが有効になるようにすることは可能ですか？

ここに興味のある人のためにいくつかの良いリンクがあります：

• http://www.projectatomic.io/docs/docker-building-images/-上記の手法を使用してイメージを構築する方法。 つまり、画像のrunからbuildします。
• https://blog.afool​​ishmanifesto.com/posts/how-to-enable-ptrace-in-docker-1.10/-その他

ビルドを変更して特定の特権操作を必要としないため、この機能は不要であるというさまざまな主張をさまざまな人から見てきましたが、「dockerindocker」の場合の対処方法についての提案はありません。 ビルドでdockerコマンドを実行する必要がある場合、たとえば、このイメージ内に出荷するイメージをプルダウンしたり、サブイメージをビルドしたりする場合、何らかの特権なしでこれを行うにはどうすればよいですか。ビルドオプション？

今のところ、 docker runとdocker commitを使用してこれを回避しますが、 docker buildがこのユースケースをサポートできれば素晴らしいと思います。

@scjodyあなたが望むように

@ cpuguy83この場合に何が起こっているのかはマージされたら

こんにちは、私は私の名前をお願いします-実装-この帽子に投げたいです。 それとも、誰かが私を指摘する可能性のある私の問題（ここではdocker noob）に対する別の解決策がありますか？

公式のcentos / systemdイメージに基づいてイメージを構築し、Saltstackでプロビジョニングしようとしています。 これには、特権モードなしでは実行できない（AFAIK）systemdを使用してsalt-minionデーモンを起動（および場合によっては再起動）する必要があります。

@onlyaneggそのような状況では、Saltstackがビルダーの機能を大幅に置き換えていると思います。 各RUNステートメントは新しいコンテナーで実行され、その時点で前のビルドコンテナーが停止され、イメージ/レイヤーにコミットされることに注意してください。

コンテナーを実行してビルドを実行し、結果（ docker commit ）をコミットすることを検討しましたか？

返信ありがとうございます、@ thaJeztah。 それがRUNディレクティブが行ったことだとは思いませんでした。 私はこの問題のほとんどを読んだので、 docker build -> docker run -> docker commit回避策を知っています。これは、私がやることになるでしょう。 私は、1つのファイルに自分の画像を記述させることに賛成です。 たぶん、私はそれらすべてのステップをパッカーポストプロセッサーに入れることができ、それから私はそれを手に入れるでしょう。

なぜこれがそんなに無視されるのですか？ コンテナー、kubernetes、minikube、およびCIでのDockerの使用と開発環境の統合では、この機能は非常に重要です。

@onlyaneggは、特権モードなしでサービスを再開できるはずです。 それを示すDockerfileがある場合（つまり、「このDockerfileの8行目のRUNコマンドは特権モードが必要なため機能しません」）、私は喜んで見ていきます！

@derberg正確に！ コンテナ、CI、CDの場合、（セキュリティの意味で）ビルドツールを含めることができることが重要です。 特権モードを許可する場合は、Jenkins、Travis、CodeshipなどのCIツールの使用方法を大幅に変更する必要があります。同じ質問：特権モードを必要とするDockerfileがある場合は、代替案を提案させていただきます。

ありがとうございました！

@jpetazzoは、Dockerを内部に含むDockerイメージを取得しようとします。

FROM ubuntu:16.04

# Get dependencies for curl of the docker
RUN apt-get update && apt-get install -y \
    curl \
    sudo \
    bash \
    && rm -rf /var/lib/apt/lists/*

RUN curl -sSL https://get.docker.com/ | sh

今それを構築し、それを開始します。 開始後、 service docker startを実行して、Dockerデーモンを開始します。 次に、サービスのステータスを確認しますservice docker status ：

• 特権フラグのステータスはOKで、問題なくコンテナを起動できます
• フラグがないと、起動しません

@jpetazzo ech、あなたがhttps://github.com/jpetazzo/dindの作成者であることに気づきましたdockerコンセプトのdockerを知っています:)

とにかく、実行には特権フラグが必要であることに注意してください。 これで、ある環境で作業し、コンポーネントがプリインストールされたminikubeなど、すでにいくつかの事前構成されたものが内部にある、開発用の統一された環境を望んでいる人々のグループを想像できます。

では、NFSまたはSMB共有をdocker buildにマウントする方法はまだありますか？

@derbergビルドコンテナが--privileged実行している場合でも、これらの手順は機能しません。 dockerパッケージ（およびインストールスクリプト）は、（たとえば）Ubuntu16.04にカーネルパッケージをインストールします。
これが、 --privilegedがdocker buildにとって悪い考えである理由です。これは、_host_で変更を加えることができるためです。

dockerは_running_時に特権を必要としますが、インストール自体はこれを必要としません。 たとえば、イメージにdockerをインストールするために実行する手順は次のとおりです。

docker build -t foo -<<'EOF'
FROM ubuntu:16.04

RUN apt-get update && apt-get install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    software-properties-common \
    && rm -rf /var/lib/apt/lists/*

RUN curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
RUN add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu xenial stable"
RUN apt-get update && apt-get install -y docker-ce \
    && rm -rf /var/lib/apt/lists/*
EOF

そして、あなたはそれをうまく実行することができます（私はここで--privilegedますが、おそらくもっときめ細かい権限が可能です）：

docker run -it --rm --privileged -v /var/lib/docker foo dockerd --debug

特権モードでDockerイメージを作成する必要がある人のために、この問題を回避する方法を次に示します。 すべてのケースを解決できるわけではありませんが、一部のケースでは役立つ場合があります。

このメソッドには、Dockerfile、docker-compseファイル、およびシェルスクリプトが必要です。

Dockerfile

これは、イメージを作成するために必要なものと同じです。 唯一の違いは、特権操作を行う必要がある場所で停止し、それらを含めないことです。 これらは、docker-composeによってスクリプトとして実行される必要があります。 例えば：

FROM ubuntu:16.04
RUN apt-get update && apt-get install <your packages>
# And more commands
......

## Below are the operations you intended to run in privileged mode when building the image, which does not work.
# More commands....
## But they now are moved to a separated shell script and it will be included in the image
COPY further-commands-to-run-in-privileged-mode.sh /

特権モードで実行する必要のあるその他のコマンドは、 further-commands-to-run-in-privileged-mode.sh 。 これはイメージに含まれており、後でDockerComposerによって実行されてビルドプロセスが完了します。

Docker構成ファイル

作成ファイルが鍵となります。 最初にDockerfileの上からイメージをビルドし、そのイメージから特権モードでコンテナーを起動し

version: '3'

services:
  your_service:
    container_name: your_container
    # First build the image from the Dockerfile
    build:
      # Change this to where you keep above Dockerfile
      context: ../docker-build
    image: "your_image_name:your_image_tag"

    # Then start a container from the just built image in privileged mode to finish what's left
    entrypoint: /further-commands-to-run-in-privileged-mode.sh
    privileged: true

イメージを作成する

以下の手順は、シェルスクリプトに保存することもできます。

# First build the image and container(in privileged mode)
docker-compose -f docker-compose.yml up

# Then commit the temporary build container to a new image, change the ENTRYPOINT to what you want
docker commit \
    -c 'ENTRYPOINT ["/bin/bash"]' \
    <build container name> \
    <final image name>:<final image tag>

# Remove the temporary build container
docker rm <build container name>

@thaJeztahインストールに問題はありません。Dockerサービスを開始し、いくつかのイメージをプルして、箱から出してすぐにイメージで利用できるようにすることに問題があります。

次のスクリプトをDockerfileに追加すると、Dockerサービスが起動しないことがわかります

#!/bin/bash

service docker start

sleep 20

service docker status

docker pull busybox

@derberg OK、なるほど！ _個人的に_、 dindコンテナに画像を含めたい場合は、それらをダウンロードし（たとえば、 reg ）、コンテナの起動時に最初にロードします。 どうして？ ビルド中にイメージをプルすると、イメージは_同じストレージドライバーでdindが開始された場合にのみ機能するため_。 つまり、画像が他のマシンで機能する場合と機能しない場合があります。

また、画像が大きい場合（つまり、 busyboxまたはalpine ）、非常に大きなDinD画像になります...

私はあなたの最終的なユースケースについてもっと知りたいです–巨大なDinD画像を焼くよりも効率的な方法を見つけるのを手伝うことができると確信しているからです:-)

（それ以外の場合、 @ kramlによって提案されたソリューションはかなりエレガントです！）

https://github.com/moby/moby/blob/master/contrib/download-frozen-image-v2.shも参照して
bash + curl + tarのみを使用して画像をダウンロードします。
ここで使用します： https ：

@jpetazzoは、すでにそのような回避策build-run-commitで実行していますが、ええ、それは私の観点からはまだ回避策です。 ユースケースは、kubernetesとminikube環境に関連してかなり具体的であり、現時点でできることは何もありません。 今のところ、dockerをデーモンとして使用してのみdockerでminikubeを起動できましたが、virtualboxまたは他のvmドライバーを使用しても機能しなかったため、 dindアプローチに依存しています

インストーラーがsysctlコマンドを実行しようとして失敗した、レガシーアプリケーション（ごく普通のユースケース）を含むイメージをビルドしようとすると、この問題が発生しました。

このスレッドに戻って、docker buildコマンドにある種の特権機能を追加する方法の問題について4年間（!!!）を前後に確認すると、この状況で使用可能なオプションは次のいずれかであるように見えます。インストーラーを変更してsysctl呼び出しを削除する、またはマルチステージビルド->実行->コミットパイプラインを変更するための厄介なsedコマンドの束。 @derbergに同意しdocker buildコマンドが失敗した場合に、さまざまなアプリケーションやデータベースのインストールに関する問題を報告する人がたくさんいます。

この時点で、docker runコマンドは、「-cap-addおよび--cap-dropを使用した機能のきめ細かい制御」に加えて、広範な「特権」オプションをサポートしています。 ですから、セキュリティ上または技術上の異議は議論の余地があると思います。 特権実行オプションが「--cap-add」および「--cap-drop」とともに追加された場合、セキュリティを重視するエンジニアは、特権ビルドを制限して、ビルドに必要な特定の機能のみを含めることができます。

やあ 、

私は以前にこれをすでに報告しました、同じ問題。

パッケージ化ツールとしてdockerを使用して、VMとコンテナーで同じユーザーIDを使用してVMごとに1つのコンテナーを実行したい場合はどうでしょうか。

これに関連するセキュリティ上の懸念はまだありますか？

この問題に遭遇しました。 ビルドに機能を実際に使用できます。

この問題にも遭遇しました。
DockerをCI / CDスレーブとして使用する場合、スレーブDockerイメージをビルドするときにCI / CDビルド/テストツールチェーンをインストールするためにdocker build特権権限が必要になる可能性がある場合に非常に便利です。
私はこの機能を何年も待っています、そしてそれが将来サポートされることを本当に望んでいます。

Dockerイメージの特権に関して開発者から多くの反発がある理由を私は本当に理解していません。
ユーザーが自分の足を撃ちたいのなら、彼らにさせてみませんか？ 警告メッセージを入れるだけで、それだけです。 同じことを達成するための回避策はすでにありますが、本当にそれを必要とするユーザーにとってそれを簡単にしてみませんか？
4〜5年経ちましたが、これについては進展がありません。
ただすごい...

現在のところ、この機能もまだ実装されていません。
RUN --cap-add = SYS_PTRACE
これは多くのユーザーのニーズに合うでしょう。

GentooLinuxホストでこのDockerfileをビルドする方法を提案してください。

FROM gentoo/stage3-amd64
# Download and extract latest portage
RUN wget http://distfiles.gentoo.org/snapshots/portage-latest.tar.bz2 && \
    wget http://distfiles.gentoo.org/snapshots/portage-latest.tar.bz2.md5sum && \
    md5sum -c portage-latest.tar.bz2.md5sum 
RUN tar -xjvf portage-latest.tar.bz2 -C /usr
RUN emerge dev-lang/go

dev-lang / goを出現させるときにこのエラーが発生するため：

##### Building Go bootstrap tool.
cmd/dist
 * /var/tmp/portage/sys-apps/sandbox-2.12/work/sandbox-2.12/libsandbox/trace.c:_do_ptrace():75: failure (Operation not permitted):
 * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): Operation not permitted
/usr/lib64/libsandbox.so(+0xb692)[0x7fd10e265692]
/usr/lib64/libsandbox.so(+0xb778)[0x7fd10e265778]
/usr/lib64/libsandbox.so(+0x6259)[0x7fd10e260259]
/usr/lib64/libsandbox.so(+0x6478)[0x7fd10e260478]
/usr/lib64/libsandbox.so(+0x7611)[0x7fd10e261611]
/usr/lib64/libsandbox.so(execve+0x3f)[0x7fd10e2634ff]
bash[0x41d8ff]
bash[0x41f387]
bash[0x420138]
bash[0x4219ce]
/proc/330/cmdline: bash ./make.bash 

 * ERROR: dev-lang/go-1.9.2::gentoo failed (compile phase):
 *   build failed
 * 
 * Call stack:
 *     ebuild.sh, line 124:  Called src_compile
 *   environment, line 1034:  Called die
 * The specific snippet of code:
 *       ./make.bash || die "build failed"
 * 
 * If you need support, post the output of `emerge --info '=dev-lang/go-1.9.2::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=dev-lang/go-1.9.2::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/dev-lang/go-1.9.2/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-lang/go-1.9.2/temp/environment'.
 * Working directory: '/var/tmp/portage/dev-lang/go-1.9.2/work/go/src'
 * S: '/var/tmp/portage/dev-lang/go-1.9.2/work/go'

--cap-add=SYS_ADMIN --device /dev/fuseまたは--privilegedなしで実行するにはどうすればよいですか？

RUN apt-get -y install unionfs-fuse
RUN unionfs-fuse -o cow dir1=RW:dir2=RO dir3/

エントリポイントの別のbashファイルでそれを行うことができますが、単一のDockerfileが必要です

@ amd-nickビルド中のRUN unionfs-fuse ...行にどのように期待しますか？ それが機能したとしても、ファイルシステムはその単一のRUN間にのみマウントされ、次のステップで実行されなくなります。

@thaJeztah私に説明するのは難しいです。 このリポジトリを変更しようとしています。 建物のこの行をスキップできますか？

やあ

dockerビルドは、ゼロ「0」で始まるホスト名をランダムに選択します。これにより、アプリケーションが破損します。このような場合、DockerFile内で「hostname」を実行しようとしましたが、同じ問題が発生しました。

また、RUNPを使用してDockerビルドを実行するオプション、またはビルド中にホスト名を選択するオプションを取得したいと思います。

こういうイメージをカニコで実行しましたが、 docker run "build"コマンドを--cap-add=SYS_PTRACE呼び出すと、正常にビルドされたようです。 結果のtarballをローカルにロードするのに少し問題がありますが、overlayfsを使用できないため、RAMの使用量が少し高く、レイヤーキャッシングは引き続きWIPです。 レジストリにプッシュすればうまくいくかもしれませんが、まだ試していません。

docker run --cap-add=SYS_PTRACE --rm -v $(pwd):/workspace gcr.io/kaniko-project/executor:latest --dockerfile=Dockerfile --context=/workspace --tarPath=/workspace/test.tar --destination=test  --single-snapshot

この機能があると、Redhat / CentOSベースイメージ上でPuppetを介してDockerイメージを構築する作業に大いに役立ちます。

前回の投稿以来、カニコの変更点をフォローアップしてきました。 それらはもはやメモリ内でtarballを実行しておらず、ディスク上でtarballを実行しています。これは、大きなイメージを記述するDockerfileのサポートを意味します。 レイヤーキャッシングはまだWIPですが、現時点ではベースイメージをキャッシュするオプションがあります（つまり、現在、高速のRUN反復保存と実行のような作業はありませんが、 alpine 、 ubuntuキャッシュできます。

それはの私が@maneamariusを構築することに成功してきた状態でだのGentoo画像にGolangを出Dockerfileを私がしたので：どのような方法（EDITでの@maneamariusを変更せずに、このプロジェクト/デモでDockerfileを変更して、gentooベースイメージをこの投稿の時点でlatestであったバージョンに固定する必要がありました。それ以外の場合は、まだ変更されていません。 ）：

https://github.com/nelsonjchen/kaniko-privileged-maneamarius-moby-1916

また、Azure Pipelinesを構成して、DockerfileをKanikoを使用して--cap-add=SYS_PTRACEイメージにビルドし、Kanikoの出力tarballをロードし、生成されたイメージでgo versionを実行します。 インタラクティブな「生命の証明」が面白いと思いました。 ここでの以前のコメントのいくつかはCIシステムについても懸念していたので、パブリックCIシステムも機能するように構成することにしました。 ところで、Travis CIが検討されましたが、ビルド出力が長すぎて終了し、Azureは166k行の出力に完全に満足しています。 Dockerfileが約70k少ない出力行でビルドされた場合、TravisCIで成功した可能性があります。 Azureパイプラインビルド出力へのリンクは、READMEの上部にあります。

buildahLukeを使用する

この機能はdocker buildx build --allow security.insecureとして利用できるようになったため、この問題を解決します。

https://github.com/docker/buildx/blob/master/README.md# --allowentitlement
https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md#run --- securityinsecuresandbox

@AkihiroSuda Dockerをバージョン19.03に更新して、 buildxを試してみました。 あなたが言ったコマンドを試していたとき、それは私にエラーを与えました

$ docker buildx build --allow security.insecure -t sample-petclinic -f Dockerfile .
[+] Building 0.0s (0/0)                                                                                                                                                         
failed to solve: rpc error: code = Unknown desc = entitlement security.insecure is not allowed

Docker version ：

Client: Docker Engine - Enterprise
 Version:           19.03.2
 API version:       1.40
 Go version:        go1.12.8
 Git commit:        c92ab06
 Built:             Tue Sep  3 15:57:09 2019
 OS/Arch:           linux/amd64
 Experimental:      true

Server: Docker Engine - Enterprise
 Engine:
  Version:          19.03.2
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.8
  Git commit:       c92ab06
  Built:            Tue Sep  3 15:55:37 2019
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

buildxドキュメント： For entitlements to be enabled, the buildkitd daemon also needs to allow them with --allow-insecure-entitlement

ありがとう@AkihiroSuda 。 今はうまくいきました。

別のユースケースを追加するだけです。
テストデータベースを使用して、ibmdb2コンテナーのdockerfileビルドを修正しようとしています。
IBMはハブからv10イメージを削除しました。 ただし、v11DBイメージは--privilegedでのみ始まります。
そのため、db2は特権なしでは起動しないため、Dockerfileでデータベースを設定するすべてのコードが機能しなくなります。 :(
dockerrunとdockercommitを使用すると、複雑な回避策があるようです。
生産的なビルドパイプラインでは、これにより多くの複雑さが増します。

私は次のように聞いているhttps://github.com/maneamariusにhttps://github.com/moby/moby/issues/1916#issuecomment -361173550

これをサポートするのはなぜそんなに大事なのですか？ ビルドは内部で実行を実行します。

この特定のユースケースでは、特権ビルドオプションが一種の「下位互換性」をサポートします。Web調査後にこの問題が発生したのは私だけではないことを私は知っています。

@uvwildこれがユースケースに役立つかどうかはkanikoを使用してビルドしてみることができます。イメージはDockerデーモンなしでビルドされ、たらイメージを抽出できます。kanikoを使用すると、コンテナーを実行するのと同じようになります。 --privilegedまたは--cap-add <capability which is needed>を使用すると、問題が解決する可能性があります。

私はあなたが期待していた完全な解決策ではありませんが、ビルドパイプラインに適合する可能性のあるより簡単な回避策を受け入れます。

編集：@ alexey-vostrikovが言ったように、 buildahは、イメージを構築するために--privilegedを必要とするユースケースにとってより実現可能なソリューションである可能性があります