☰

非共有ネームスペース内のファイルシステムイメージのマウント

tag-icon • tag-icon mount loop-device namespace unshare
非共有ネームスペース内のファイルシステムイメージのマウント

私はそれをunshareローカルプロセスにマウントするのと同じタスクを実行するために使用します。ルートアクセスは不要、例えば：

unshare -mr bash mount --bind a b

（はい、これは少し愚かなようです。実際のユースケースでは、unshareバインドマウントを実行するbashスクリプトを実行しています。

ただし、インストールを繰り返しようとすると失敗します。

ryan@DevPC-LX ~/stuff/util-linux master $ unshare -mr mount -o loop x.img a
mount: no permission to look at /dev/loop<N>

:/

mknod偽のループデバイスを作成し（root以外のユーザーは取得できない権限が必要です）、手動で実行しlosetup（まだroot権限が必要です）、うまくいかないいくつかの操作を試しました。

もちろんそうすることもできますがchown myuser /dev/loop*、深刻なセキュリティ問題になる可能性があります。

また、guestmount私のユースケースに比べて遅すぎてfuseext2書き込みモードでデータが失われる可能性に関する警告が表示されます（また遅すぎます）。

これを行う方法はありますか？ありますか？

答え1

明らかにわかるように、ループインストールの作成は2つのステップで構成されています。

  1. ループ機器の設定
  2. インストールする

もちろん、myuser /dev/loop* を chown することもできますが、これは主なセキュリティ問題になる可能性があります。

私はこれが適切なループデバイスの作成を可能にすると信じています（アクセス権限を与えることによって/dev/loopcontrol）。ループデバイスの表示に影響を与える可能性のある名前空間の種類があるかどうか疑問に思います。これにより、これをより安全に実行できます。

ステップ2はまだ試すことができません。ユーザーネームスペースを使用すると、ユーザーは新しいマウントを作成できる新しいマウントネームスペースを作成できますが、非常に制限されています。CAP_SYS_ADMIN 初期名前空間でブロックデバイスをまだインストールする必要があります。user_namespaces(7)言ったように…

ただし、ブロックベースのファイルシステムのマウントは、初期ユーザーネームスペースにCAP_SYS_ADMINを保持するプロセスによってのみ実行できます。

ループデバイスはファイルベースのブロックデバイスなので、まだ使用できません。これは残念であり、安全に作業する方法があるべきだと思います。しかし、私の考えではここには複雑な問題がたくさんあるようだ(特に setuid）これがまだ実装されていない理由です。

私が理解したところによると、実際にできることは問題を解決するだけです。おそらく画像からファイルを抽出し（最悪の状況が発生し、特定の形式を直接処理するためのツールがない場合は、一時仮想マシンにインストールしてこれを実行できます）、結果ディレクトリをバインドマウントできます。

答え2

共有解除を実行するには、別々のインストールスペースを作成するためのroot権限が必要です。

私はあなたが望むことをしているように見えるこれを試しました（私の考えでは）：

Ishtar:> mkdir -p /tmp/unshare/home
Ishtar:> cd /tmp/unshare
Ishtar:/tmp/unshare> sudo unshare -m /bin/bash
Ishtar:/tmp/unshare# mount --rbind /home/packages /tmp/unshare/home
Ishtar:/tmp/unshare# tty
/dev/pts/4
Ishtar:/tmp/unshare# # ls home
BUILD@      RPMS@     build/           linux@    sources/           tmp/
BUILDROOT@  SOURCES@  buildroot/       logs/     specs/
OSbuild/    SPECS@    config-scripts/  perlsrc/  srpms/
OTHER/      SRPMS@    debug@           rpms/     sysvinit-288.spec

したがって、上記のプロセスは '/home/packages@ /tmp/unshare/home.dll'をインストールしました。

他のttyウィンドウで、すべてのユーザーに対して/tmp/unshare/homeに何があるかを確認できます。

Ishtar:/> tty
/dev/pts/5
Ishtar:/> ll /tmp/unshare/home
total 0
Ishtar:/> cd tmp/unshare
Ishtar:/tmp/unshare> sudo
Ishtar:/tmp/unshare# ls home
Ishtar:/tmp/unshare# ll home
total 0
# create file in original "bound" dir from 1st usr above:
Ishtar:/tmp/unshare# touch /home/packages/PACKAGES.DIR 
Ishtar:/tmp/unshare# ll home  #home still empty
total 0
Ishtar:/> tty
/dev/pts/5
# now on other user again
Ishtar:/tmp/unshare# tty
/dev/pts/4
Ishtar:/tmp/unshare# ls home
BUILD@        RPMS@     buildroot/       perlsrc/  sysvinit-288.spec
BUILDROOT@    SOURCES@  config-scripts/  rpms/     tmp/
OSbuild/      SPECS@    debug@           sources/
OTHER/        SRPMS@    linux@           specs/
PACKAGES.DIR  build/    logs/            srpms/
#^^^ see PACKAGES.DIR appear (as created in original dir by another
# user

「pts/4」にユーザー用に「個人ディレクトリ」がマウントされたら、プログラムを実行するUIDに変更できます。

Ishtar:/tmp/unshare# su astara
Ishtar:/tmp/unshare> whoami
astara
Ishtar:/tmp/unshare> ls home/PACK*
home/PACKAGES.DIR

権限のないユーザーのマウントはまだ存在します。

保存するためにスクリプトファイルに「su to other user」を入れてから「unmount /tmp/unshare/home」を入れました（su OTHERUSERが終了すると再びルートになり、プライベートスペースをマウント解除するためです）。その後、終了できます。

これはあなたが望むものに近いですか？ - 子環境を設定してから子環境を実行するには、「root」を使用する必要があり、ルートのみが新しいマウント名前空間に作成されたマウントにアクセスできます。

（更新）ところで - unshareには、rootまたは大文字を使用して新しい名前空間でオプション設定を特別に許可する--map-root-userがあることを確認しました。マンページには（このスイッチについて）次のように記載されています。

....This makes it possible to  conveniently
gain  capabilities needed to manage various aspects of the newly
created namespaces (such as configuring interfaces in  the  net-
work  namespace  or mounting filesystems in the mount namespace)
even when run unprivileged.

これにより、ルートを必要とせずに（またはマニュアルページに示すように）開発ループを管理できます。 CAP_SYS_ADMINは、おそらくこれを行うために必要な上限です。

関連情報