☰

LXCの子GID / UIDと権限のないユーザーのユーザーはいますか？

tag-icon • tag-icon lxc shadow userns
LXCの子GID / UIDと権限のないユーザーのユーザーはいますか？

ユーザーを使用する場合（私の場合はLXCを介して）、権限のないユーザーに一連の子GIDとUIDを割り当てます。リソースを見る：subuid(5)、subgid(5)、newuidmap(1)、newgidmap(1)、user_namespaces(7)。

その後、スコープを使用でき、渡されます。システムアカウントにマップします。

johnUID（およびGID）1000を持つ（ホスト）システムアカウントがあるとします。割り当てられたGIDとUIDの範囲は100000..165536です。

/etc/subgidしたがって、それぞれの項目があります/etc/subuid。

john:100000:65536

権限のないコンテナ内で「内部」が所有するファイルは、johnホストで101000が所有し、「内部」が所有するファイルはroot100000が所有するようになります。

通常、これらのスコープはホストのどの名前にも割り当てられません。

質問：

  1. ls友達により意味のある出力を提供するために、ホストシステムでこれらのUID / GIDごとにユーザーを作成できますか？
  2. johnユーザーを「所有」するホストユーザー（例：私たちの場合）がこれらのファイル/フォルダにアクセスできるようにする方法はありますか？それでは、サブスコープの有効ユーザーとユーザーの「所有者」の間で共有されるグループを作成し、それに応じて権限を設定することが唯一の合理的なアプローチですか？まあ、明らかにACLです。

答え1

  1. lsと友達により意味のある出力を提供するために、そのUID / GIDに対してホストシステムでユーザーを作成できますか？

はい、大丈夫です。ただし、そのユーザーがホストシステムのどのエントリにも権限がないことを確認する必要があります。

  • アクセスまたはパスワードを無効にする、
  • 利用可能なログインシェルがありません。
  • 書き込み可能なホームディレクトリはありません。

また、ユーザー名が重複しないように注意してください。

/etc/passwd以下は、ゲストと/etc/groupファイルを使用してホストシステムで適切なユーザーを作成するサンプルスクリプトです。すべての名前にはコンテナ名が接頭辞で付けられ、すべてのIDはコンテナのUIDと一致するように指定された値にインクリメントされます。

#! /bin/sh

# Path to guest's `/etc' directory.
guest_etc=/var/lib/lxc/mycontainer/rootfs/etc
# Guest's name, used as login prefix and inside GECOS field.
guest_name=mycontainer
# Increment to be applied to UIDs and GIDs (= range start).
uid_incr=100000
gid_incr=$uid_incr

guest_passwd=${guest_etc}/passwd
guest_group=${guest_etc}/group

exec <$guest_group
while IFS=":" read name pass gid null; do
    gid_new=$( expr $gid + $gid_incr )
    if ! getent group $gid_new >/dev/null; then
        addgroup --system --gid $gid_new "${guest_name}_${name}"
    fi  
done

exec <$guest_passwd
while IFS=":" read login pass uid gid gecos null; do
    uid_new=$( expr $uid + $uid_incr )
    gid_new=$( expr $gid + $gid_incr )
    if ! getent passwd $uid_new >/dev/null; then
        adduser --system --home /nonexistent --no-create-home \
            --shell /bin/nologin --uid $uid_new --gid $gid_new \
            --gecos "\"$guest_name container user (${gecos})\"" \
            "${guest_name}_${login}"
    fi  
done

アクセスできないホームディレクトリに関する警告は、正常で予想されるものです。これは/nonexistent実際の目的ではありません。

  1. ユーザーを「所有」するホストユーザー（この例ではJohnなど）がこれらのファイル/フォルダにアクセスできるようにする方法はありますか？それでは、サブスコープの有効ユーザーとユーザーの「所有者」の間で共有されるグループを作成し、それに応じて権限を設定することが唯一の合理的なアプローチですか？まあ、明らかにACLです。

私の考えでは、これはそれ自体で質問を受ける価値があります。

コンテナのコンテンツは、コンテナ所有者のUIDとは異なるUIDが所有しているため、コンテンツにアクセスできません。子ユーザーのこのルールに例外があると想像できますが、現在はわかりません。関連質問少し時間がかかりましたが、まだ答えがありません。）

これ/etc/subuidはファイルであり、現在特定のプロセスがあるUID / GIDから別のUID / GIDに切り替えることを許可または拒否するために/etc/subgid（1）でのみ使用されます。newuidmap牧場の所有者に他の権利を与えません。

したがって、ソリューションはケースごとに設計する必要があります。しかし、ACLのアイデアに注意してください。ホストのUID 1000が読み取り可能なようにコンテナのファイルにいくつかのACLを配置すると仮定すると、これはコンテナのUID 1000のコンテナユーザーも同じレベルの権限を持つことを意味します。

関連情報