プロセスはどのように異なる名前空間の機能を持つことができますか?

プロセスはどのように異なる名前空間の機能を持つことができますか?

名前空間と関数間の相互作用について考えています。時々私はuser_namespaces(7)で次の表現を偶然見つけます。

Holding CAP_SYS_ADMIN within the user namespace that owns a
process's mount namespace allows that process to ...

私は次のことを理解しています:

  • 各非ユーザーネームスペースNは、ユーザーネームスペースUに属します。これは、UからNを作成したプロセスによって決定されます。

  • 機能は、プロセス(より正確にはスレッド)またはファイルの属性です。この議論のためには、今すぐの過程を考えてみるだけで十分だと思います。

  • 各名前空間タイプに対して、各プロセスはそのタイプの1つの名前空間にあります。

  • 階層を形成するのは、PIDネームスペースとユーザーネームスペースです。文書の表現について私が理解したのは、プロセスPが名前空間Bの子である名前空間Aにあっても、まだPがBにあるとは言えません。 PはAにあり、PはAに位置するためです。タイプの名前空間。つまり、名前空間の親関係をコレクションの埋め込みと混同しないでください。

今フレーズ

Holding a capability within the user namespace U that owns a
process's mount namespace M allows that process P to ...

プロセスPからマウントネームスペースM(/proc/P/ns/mnt)に移動し、プロセスが属するユーザーネームスペースUを見つけ、(ioctl_ns(2))プロセスにUの機能があるかどうかを確認するように指示します。 。

これが私が理解していない最後の部分です。 Pは必ずしもUに属する必要はありませんが、どのようにそこで能力を持つことができますか?プロセス×ユーザーネームスペース↦関数マッピングはありますか?また、UはUIDに関連付けられていますが、機能はユーザーIDの属性ではありません。

ベストアンサー1

実際、答えは私の鼻のすぐ下にあるuser_namespaces(7)ですでに関連部分を裏返しているようです。以下に引用します。

       1. A process has a capability inside a user namespace if it is a member
          of that namespace and it has the capability in its  effective  capa‐
          bility  set.  A process can gain capabilities in its effective capa‐
          bility set in various ways.  For example, it may execute a set-user-
          ID  program  or an executable with associated file capabilities.  In
          addition,  a  process  may  gain  capabilities  via  the  effect  of
          clone(2), unshare(2), or setns(2), as already described.

       2. If  a process has a capability in a user namespace, then it has that
          capability in all child (and further removed descendant)  namespaces
          as well.

       3. When  a  user namespace is created, the kernel records the effective
          user ID of the creating process as being the "owner"  of  the  name‐
          space.   A  process that resides in the parent of the user namespace
          and whose effective user ID matches the owner of the  namespace  has
          all  capabilities in the namespace.  By virtue of the previous rule,
          this means that the process has all capabilities in all further  re‐
          moved  descendant  user  namespaces  as  well.  The NS_GET_OWNER_UID
          ioctl(2) operation can be used to discover the user ID of the  owner
          of the namespace; see ioctl_ns(2).

したがって、実際にはプロセス×名前空間×機能の三元関係があります。私の理解は次のとおりです。

  1. プロセスは、その有効な機能セット内で自分が属するユーザーの名前空間にこれらの機能を明確に持っています。ここでは驚くことではありません。

  2. ユーザーの名前空間階層を抑制する機能があります。驚くべきことではありません。

  3. プロセスPがユーザー名前空間Uのメンバーであり、Uが子ユーザー名前空間U 'を持ち、PのeUIDがU'のUIDである場合、PはU'のすべての機能を持ちます。

残念ながら、3回を私が正しく理解したかどうかはわかりませんが、次の実験では観察に失敗しました。

$ id -u
1000
$ echo $$
4083
$ readlink /proc/4083/ns/user
user:[4026531837]
$ sleep 10001 &
[1] 4101
$ readlink /proc/4101/ns/user
user:[4026531837]
$ ps -p 4101 -o pid,euid,comm
    PID  EUID COMMAND
   4101  1000 sleep

これで、sleepユーザーネームスペース4026531837に常駐し、eUID 1000を持ちます。

$ unshare -r
# echo $$
4111
# readlink /proc/4111/ns/user
user:[4026532574]

外部から見ると、IDが4026532574のユーザーネームスペースには、親ユーザーネームスペースが4026531837でUIDが1000です(下記参照)。したがって、上記の基準を満たす必要があります。ただし、スリープ処理の拡張機能は表示されません。

# grep Cap /proc/4101/status
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000

newwをインストールする必要があるかもしれませんが、/procプロセスに影響を与えずにインストールする方法がわかりませんsleep...

サイドノート

さまざまなコードスニペットとマニュアルページでいくつかの特別なものを集めました。エンスラエル名前空間階層を研究します。上記の例では、初期名前空間で実行されたときに次のように生成します。

$ nsrel 4111 user
ID          TYPE      PARENT      USERNS      UID
4026532574  User      4026531837  4026531837  1000
4026531837  User      <oos>       <oos>       0

プロセス4111は、ユーザネームスペース4026532574に表示される。このユーザーネームスペースの親ネームスペースは4026531837で、UID 1000に属しています。

おすすめ記事