☰

ピエロコンテナ用

tag-icon • tag-icon linux lxc userns
ピエロコンテナ用

特権LXC（1.0.3）コンテナ（私が知っている部分）をビルドしてから、無許可実行のために正常に移行するにはどうすればよいですか？つまり、テンプレート（通常は下）を直接debootstrap変更または調整して、正しく機能するようにしたいと思います。lxc-ubuntu/usr/share/lxc/templates

それで私がこの質問をするのです。lxc-ubuntuテンプレートを見ると、次のことがわかります。

# Detect use under userns (unsupported)
for arg in "$@"; do
    [ "$arg" = "--" ] && break
    if [ "$arg" = "--mapped-uid" -o "$arg" = "--mapped-gid" ]; then
        echo "This template can't be used for unprivileged containers." 1>&2
        echo "You may want to try the \"download\" template instead." 1>&2
        exit 1
    fi
done

ただし、参照されているテンプレートでおよびそれ以降を使用するLXC_MAPPED_GIDことには特別な内容がないようです。実際に行うことは、ファイルの所有権（+）を調整することだけです。しかし、テンプレートの拡張属性は、所望の「魔法」を達成するために微調整された可能性がある。LXC_MAPPED_UIDlxc-downloadchgrpchowndownload

コメントからStéphane Graberによるブログ投稿スティーブンはある評論家にこう言いました。

残念ながら、これを行う簡単な方法はありません。権限のないコンテナーの構成と一致するようにコンテナー構成を更新し、コンテナーのディレクトリーを実行する権限のないユーザーに移動し、Sergeのuidshiftプログラムを使用して所有権を変更する必要があります。すべてのファイル。

...そして：

  • 見るhttps://jenkins.linuxcontainers.org/downloadテンプレート用に作成されたパッケージの場合
  • チェックuidmapshiftアウト：ここ
    • 手順は、概説されlxc-usernsexec -m b:0:1000:1 -m b:1:190000:1 -- /bin/chown 1:1 $fileているように機能するようです。lxc-usernsexec(1)

しかしこれ以上の指示はなかった。

だから私の質問は：root私が自分で構築した（所有および全体）一般的な（権限のある）LXCコンテナを権限のないコンテナに移行するにはどうすればよいですか？スクリプトなどを提供できない場合でも、考慮すべき事項と権限のないLXCコンテナを実行する機能にどのような影響を与えるかを知っておくとよいでしょう。スクリプトを直接作成して解決策を見つけたら、この質問に対する回答として投稿することを約束できます。 :)

メモ:Ubuntu 14.04を使用していますが、これは一般的な質問。

ベストアンサー1

私はKVM仮想マシンを無許可のLXCに移動するのと非常によく似た作業をしました。

これにはシステムコンテナを使用していますが（起動時に自動的に起動できるように）、マッピングされたUID / GID（ユーザーネームスペース）を使用します。

  1. / etc / subuid、subgidを編集します（uid / gids 10M-100Mをルートにマップし、コンテナあたり100Kを使用しました）。
  2. 最初のコンテナでは、/var/lib/lxc/CTNAME/config で u/gid 10000000-10099999 を使用します。
  3. /var/lib/lxc/CTNAME/rootfsにコンテナストレージをマウントする（または別々のボリューム/データセット/コンテナごとに何も使用しない場合は何もしません）
  4. chown 10000000:10000000 /var/lib/lxc/CTNAME/rootfs
  5. setfacl -mu:10000000:x /var/lib/lxc (または単に chmod o+x /var/lib/lxc)
  6. lxc-usernsexec -mb:0:10000000:100000 --/bin/bash

これで、最初のコンテナユーザーの名前空間にいます。すべてが同じですが、プロセスではuidが0であると思いますが、実際にはホストネームスペースではuidが10000000です。 /proc/self/uid_mapをチェックして、uidがマッピングされていることを確認してください。もはや/rootで読むことができず、誰も/どのグループも所有していないようです。

ユーザーの名前空間では、元のホストからrsyncします。

ユーザーの名前空間の外部では、/var/lib/lxc/CTNAME/rootfs のファイルが、元のインストールと同じ予想 uid に属さず、10000000+remote_uid に属していることがわかります。これがあなたが望むものです。

それはすべてです。データを同期するときは、コンテナの /etc/fstab からすべてのエントリを削除してマウントを試みずに起動する必要があります。変更する必要がある他のものがあるかもしれません。コンテナ化された展開に対してLXCテンプレートが実行する作業を確認してください。カーネル、grub、ntp、およびコンテナのすべてのハードウェアプローブパッケージを完全に削除できます（実行する必要はなく、ユーザーの名前空間からコンテナにchrootできます）。

実行中のリモートVMがない場合は、raw VMストレージをホスト名前空間にマウントし、rsync / SSHをローカルホストに再マウントすることもできます。効果は同じです。

特権コンテナーを非特権コンテナーに変更する場合は、uid/gid マッピングを追加し、上記のマッピングをコンテナー構成に追加してから、次のこともできます。

for i in `seq 0 65535`; do
  find /var/lib/lxc/CTNAME/rootfs -uid $i -exec chown $((10000000+i)) \{\} \;
  find /var/lib/lxc/CTNAME/rootfs -gid $i -exec chgrp $((10000000+i)) \{\} \;
done

これが完了する必要があるすべてのタスクであり、今すぐ許可されていない方法でコンテナを実行できるようになりました。上記の例は非常に非効率的です。 uidshiftはより良い仕事をすることができます（しかしまだ使用していません）。

HTH。

おすすめ記事