コマンドを確認unshareし、そのマニュアルページに従って
unshare - run program with some namespaces unshared from parent
また、次の名前空間がリストされていることがわかります。
mount namespace
mounting and unmounting filesystems will not affect rest of the system.
これを行う目的は何ですか？マウントネームスペース？私はいくつかの例でこの概念を理解しようとしました。
答え1
Runはunshare -m呼び出しプロセスにマウント名前空間のプライベートコピーを提供し、ファイルシステムプロパティの共有を解除し、ルートディレクトリ、現在のディレクトリ、またはumaskプロパティを他のプロセスと共有しないようにします。
それでは、上記の節は正確に何を言うのでしょうか？簡単な例を考えてみましょう。
ターミナル1：
最初の端末で次のコマンドを実行します。
#Creating a new process
unshare -m /bin/bash
#creating a new mount point
secret_dir=`mktemp -d --tmpdir=/tmp`
#creating a new mount point for the above created directory.
mount -n -o size=1m -t tmpfs tmpfs $secret_dir
#checking the available mount points.
grep /tmp /proc/mounts
最後のコマンドが私に与えた結果は次のとおりです。
tmpfs /tmp/tmp.7KtrAsd9lx tmpfs rw,relatime,size=1024k 0 0
これで、次のコマンドも実行しました。
cd /tmp/tmp.7KtrAsd9lx
touch hello
touch helloagain
ls -lFa
このコマンドの出力はls次のとおりです。
ls -lFa
total 4
drwxrwxrwt 2 root root 80 Sep 3 22:23 ./
drwxrwxrwt. 16 root root 4096 Sep 3 22:22 ../
-rw-r--r-- 1 root root 0 Sep 3 22:23 hello
-rw-r--r-- 1 root root 0 Sep 3 22:23 helloagain
それでは、このすべてのことをする上で最大の問題は何ですか？なぜこれを行うべきですか？
次に別の端末を開きます（NO2。) 次のコマンドを実行します。
cd /tmp/tmp.7KtrAsd9lx
ls -lFa
出力は次のとおりです。
ls -lFa
total 8
drwx------ 2 root root 4096 Sep 3 22:22 ./
drwxrwxrwt. 16 root root 4096 Sep 3 22:22 ../
ファイルが見えませhelloんhelloagain。ファイルを確認するためにrootとしてログインすることもありました。だから利点は、この機能を使用すると、他のルート所有プロセスでも表示または閲覧できない個人用一時ファイルシステムを作成できます。
マニュアルページunshareから
mount 名前空間 ファイルシステムのマウントとマウント解除は、ファイルシステムが明示的に共有として表示されない限り (mount --make-shared を使用、共有フラグは /proc/self/ 参照) システムの残りの部分 (CLONE_NEWNS フラグ)影響しません。 ）。
unshare --mount の後、mount --make-rprivate または mount --make-rslave を使用して、新しいネームスペースのマウントポイントを実際に親ネームスペースで共有解除することをお勧めします。
名前空間で使用されるメモリはカーネルのVFSです。最初からすぐに設定すると、root権限なしでrootユーザーである完全な仮想環境を作成できます。
引用:
この例は、次の詳細を使用して構築されました。このブログ投稿。また、この回答は以下で引用されました。素晴らしい説明マイク。これに関するもう一つの素晴らしい内容は、以下の答えで見つけることができます。ここ。
答え2
名前空間のマウントに関する非常に重要なことは完全に無視されました。
詳しくはお知らせし、味はお知らせします。
2つのマウントネームスペースを使用しても、2つの独立したファイルシステムがあるという意味ではありません。これは完全に間違っています。
はい。
マウントネームスペースAにマウントポイント/ 01があります。
次に、AでマウントネームスペースBを作成します。
これで、マウントネームスペースBに/ 01があります。
次に、Bの/ 01をプライベートに設定します。
(namespace B) # mount --make-private /01
次に、Aにファイルを作成します。
(namespace A) # touch /01/a.txt
このファイルはB / 01にあります。
次に、Bでb.txtを作成します。
(namespace B)# touch /01/b.txt
A / 01にb.txtが表示されます。
だから。マウントネームスペース間に独立性はありません。
ある名前空間のマウントポイントが別の名前空間にある別のマウントポイントのソースである場合、2つのマウントポイント間の単純ファイルと単純フォルダは100％の透明度を持ちます。マウントポイントにどのオプション（共有、プライベート、スレーブ）を割り当てるかは重要ではありません。これはまったく役に立ちません。
したがって、assginプライベートオプションを使用して新しいマウントネームスペースを作成し、新しいネームスペースのすべてのマウントポイントに対して独立したファイルシステムを取得すると考えると、これは完全に間違っています。
真の独立性は、新しいサブマウントポイントにのみ関連します。
また、新しいネームスペースに新しいサブマウントポイントを作成しても、通常、サブマウントポイントが他のマウントネームスペースとは独立しているわけではありません。重要なことは、各マウントポイントにバックエンド（物理物理ディスクなど）があることです。したがって、バックエンドを知っている場合は、それをインストールして変更できます。
(namespace A) # mount /dev/sdb1 /mnt
(namespace A) # mount --make-private /mnt
(namespace A) # unshare -m bash
(namespace B) #
名前空間Aを返す
(namespace A) # mkdir /mnt/01
(namespace A) # mount /dev/sdc1 /mnt/01
(namespace A) # mount --make-private /mnt/01
(namespace A) # touch /mnt/01/a.txt
名前空間Bにはa.txtは表示されません。
(namespace B) # ls -1al /mnt/01
何も表示されません。
だから今はすべて大丈夫です。
しかし、/mnt/01のバックエンドが/dev/sdc1であることがわかったら、このバックエンドを名前空間Bにマウントし、最後にa.txtを見ることができます。
(namespace B) # mkdir /mnt/02
(namespace B) # mount /dev/sdc1 /mnt/02
(namespace B) # ls -1al /mnt/02/a.txt
勝利
最後に、結論として、ネームスペースのマウントは難しい作業であり、本当に独立したファイルシステムを作成したり、目的の結果を得るためには、背後のすべての詳細をよく理解する必要があります。
答え3
お持ちの場合バブルラップシステムにインストールしたら、1ステップで簡単に完了できます。
bwrap --dev-bind / / --tmpfs /tmp bash
上記の例では、内部bashには/ tmpの独自のビューがあります。
@ Ramesh-sの答えからインスピレーションを得たソリューション - ありがとう！