web-dev-qa-db-ja.com

非特権LXCコンテナとは何ですか？

Linuxコンテナ（LXCコンテナ）が「非特権」と呼ばれるとはどういう意味ですか？

lxcuserns
20
0xC0000022L

非特権LXCコンテナは ser namespaces （ serns ）を利用するコンテナです。つまりホスト上のUIDの範囲をネームスペースにマッピングできるカーネル機能の例inside UID 0のユーザーが再び存在できる.

しばらくの間、権限のないLXCコンテナーについての私の最初の認識に反して、これはコンテナーが権限のないホストユーザーによって所有される必要があることを意味しません。それは唯一の可能性です。

関連は：

  1. 下位のUIDとGIDの範囲がホストユーザー（usermod [-v|-w|--add-sub-uids|--add-sub-gids]）に対して定義されていること
  2. ...そして、この範囲がコンテナ構成にマップされていること（lxc.id_map = ...）

したがって、rootでも非特権コンテナを所有できます。これは、ホスト上のコンテナプロセスの実効UIDが、マッピングによって定義された範囲内になるためです。

ただし、rootの場合、最初に従属IDを定義する必要があります。 adduserを介して作成されたユーザーとは異なり、rootには、デフォルトで定義された下位IDの範囲はありません。

また、指定する全範囲は自由に使用できるため、次の構成行を持つ3つのコンテナを使用できることにも注意してください（UIDマッピングのみを示しています）。

  1. lxc.id_map = u 0 100000 100000
  2. lxc.id_map = u 0 200000 100000
  3. lxc.id_map = u 0 300000 100000

rootが100000から400000の間の従属UIDを所有していると仮定します。私が見つけたすべてのドキュメントは、コンテナーごとに65536の従属IDを使用することを提案しています。

つまり、各コンテナに同じ範囲を割り当てる必要はありません。

40億を超える（〜2^32）可能な下位IDがあるため、ホストユーザーに下位範囲を処理するときに寛大になることができます。

Rootが所有および実行する非特権コンテナ

もう一度こすり合わせます。非特権LXCゲストは、ホスト上で非特権ユーザーが実行する必要はありません。

次のような下位のUID/GIDマッピングでコンテナを構成します。

lxc.id_map = u 0 100000 100000
lxc.id_map = g 0 100000 100000

ホスト上のユーザーrootが指定された従属ID範囲を所有している場合、ゲストをさらに制限できます。

ただし、そのようなシナリオには1つの重要な追加の利点があります（そして、はい、それが機能することを確認しました）。システムの起動時にコンテナーを自動起動できます。

通常、LXCに関する情報をWebで検索すると、権限のないLXCゲストを自動起動することはできないことが通知されます。ただし、これは、システム全体のコンテナーストレージ（通常は/var/lib/lxcなど）にないコンテナーに対してのみデフォルトで当てはまります。それらが（通常、ルートによって作成され、ルートによって開始されることを意味する）場合は、まったく別の話になります。

lxc.start.auto = 1

コンテナー設定に配置すると、うまく機能します。

権限と構成を正しく取得する

私はこれに少し苦労したので、ここにセクションを追加します。

lxc.includeで通常含まれる/usr/share/lxc/config/$distro.common.conf（$distroはディストリビューションの名前）を介して含まれる構成スニペットに加えて、システムに/usr/share/lxc/config/$distro.userns.confがあるかどうかを確認し、それも含める必要があります。例えば。：

lxc.include = /usr/share/lxc/config/ubuntu.common.conf
lxc.include = /usr/share/lxc/config/ubuntu.userns.conf

さらに、下位IDマッピングを追加します。

lxc.id_map = u 0 100000 65535
lxc.id_map = g 0 100000 65535

つまり、ホストUID 100000はrootinside LXCゲストのユーザー名前空間です。

次に、権限が正しいことを確認します。ゲストの名前が環境変数$lxcguestに格納される場合は、次のコマンドを実行します。

# Directory for the container
chown root:root $(lxc-config lxc.lxcpath)/$lxcguest
chmod ug=rwX,o=rX $(lxc-config lxc.lxcpath)/$lxcguest
# Container config
chown root:root $(lxc-config lxc.lxcpath)/$lxcguest/config
chmod u=rw,go=r $(lxc-config lxc.lxcpath)/$lxcguest/config
# Container rootfs
chown 100000:100000 $(lxc-config lxc.lxcpath)/$lxcguest/rootfs
chmod u=rwX,go=rX $(lxc-config lxc.lxcpath)/$lxcguest/rootfs

これにより、最初の試行で権限関連のエラーが発生した後にコンテナを実行できるようになります。

20
0xC0000022L

ソリューションがうまく機能した0xC0000022Lをフォローアップするために、increase-uid-gid.plPerlスクリプトを作成して、必要な所有権の変更を自動化しました。 LXCコンテナ内のファイルは適切にマッピングされます。

これがなければ、この提案されたセットアップでは、メインホストの0/rootに属するLXCコンテナーrootfs内のファイルは、LXCコンテナー自体内で65534/nobodyにマップされます。 LXCコンテナ内の0/rootにマップするには、ホスト上で100000に属している必要があります。

これはここで説明されています https://yeupou.wordpress.com/2017/06/23/setting-up-lxc-containers-with-mapped-giduid/ およびスクリプトはgitlabから直接取得できます https://gitlab.com/yeupou/stalag13/blob/master/usr/local/bin/increase-uid-gid.pl

0
yeupou