0

私は現在、Linux で CLONE_NEWNS を理解するための例を探しているので、次の実験を行いました。

シェル1で：

$ mkdir mnt
$ sudo unshare -m /bin/bash
# mount /dev/sda5 mnt/
# ls mnt
lost+found

shell2 のように:

$ ls mnt
lost+found

CLONE_NEWNS はドキュメントが述べたように新しいマウント名前空間を作成するため、shell2 の出力は空である必要があります。

まず、子の名前空間マウントが親に伝播すると思ったので、親にマウントすると、子にもマウントが表示されます!

次に、同じ親から 2 つの別個の子名前空間を作成します。1 つの子にマウントすると、もう 1 つの子にも影響します。

よくわかりません。

ps。shell1 での最初の実験で:

# readlink /proc/$$/ns/mnt
mnt:[4026532353]

シェル2で：

$ readlink /proc/$$/ns/mnt
mnt:[4026531840]

どうやら、それらは異なるマウント名前空間にあります。

4

2 に答える 2

0

別のマウント名前空間は、子名前空間の [u]mount-actions が親で表示されないことを意味します。特に、親のマウントが子に表示されないという意味ではなく、すべてのマウントが消えるという意味でもありません。

それを試すには、子名前空間で何かを[アン]マウントして、それが親名前空間に[まだ]存在するかどうかを確認してください。

于 2013-04-06T12:51:17.377 に答える
0

Linux は完全に逆行しているように見えますが、その理由は完全にはわかりません。

ただし、shell2 を使用している場合mount /dev/sda5 mnt/、shell1 ではls mntLOST+FOUND は表示されません。shell1 の子の名前空間は、親の名前空間の変更から効果的に保護されていますが、親の名前空間は子によって変更されています。親の名前空間は子によって変更される可能性がありますが、その逆はありません。

これがなぜなのかはわかりませんし、違う場合もあるかもしれませんが、私は知りません。これについては完全に間違っている可能性がありますが、上記のアクションをテストしたところ、mnt/ が shell2 にマウントされないように見えました。

あなたの問題の可能な解決策は、 unshare を使用して、すべてのルート操作を実行する一種の特権マウント名前空間を作成することです。これは、通常の非特権アカウントと操作に使用する親名前空間です。以下のようなので...

[shell1] # unshare -m bash
[shell2] # sudo -u normal-user startx
[shell1] # mount /dev/privatesecret /mnt/secretplace

...そんな感じ。明らかに、誰かがルートを取得すると、プロセスをptraceできますが、子名前空間により、[shell1]のプライベートマウントが[shell2]または他の場所の操作から完全に隠されます。それを台無しにすることができます。

そのリバースサンドボックスのことは、マウント名前空間にのみ適用されると確信しています。PID 名前空間は、子が親の PID を認識しないように適切にサンドボックス化されます。また、メモリ名前空間では、子は親よりもメモリ内で制限されます。

于 2016-11-06T07:23:31.253 に答える