☰

ユーザー名前空間内で、マウントしたファイルシステムを再マウントできないのはなぜですか?

tag-icon • tag-icon linux mount namespace
ユーザー名前空間内で、マウントしたファイルシステムを再マウントできないのはなぜですか?

https://github.com/systemd/systemd/issues/9914#issuecomment-416387637

$ uname -r
4.17.18-200.fc28.x86_64

$ unshare -U -r -m
# mkdir TMP
# mount -t tmpfs tmpfs TMP/
# mount -o remount,ro TMP/
mount: ./TMP: permission denied.

# grep TMP /proc/self/mountinfo
834 831 0:74 / /home/alan/TMP rw,relatime - tmpfs tmpfs rw,seclabel,uid=1001,gid=1001
# strace -f mount -o remount TMP/
...
mount("tmpfs", "/home/alan/TMP", 0x557c3cec9600, MS_REMOUNT|MS_RELATIME, "seclabel,uid=1001,gid=1001") = -1 EPERM (Operation not permitted)
...

バインド再マウントは正常に動作します。

 # strace -f mount -o remount,bind,ro TMP/
 mount("tmpfs", "/home/alan/TMP", 0x5615b7ebc130, MS_RDONLY|MS_REMOUNT|MS_BIND|MS_RELATIME, "seclabel,uid=1001,gid=1001") = 0

答え1

実装されていません。ただし、次のバージョンでは実装されます。

v4.18 には次のコミットが含まれています。これは、これまでサポートされていなかった具体的な理由を示すものではありません。

https://github.com/torvalds/linux/commit/bc6155d13260

fs: スーパーブロックの所有者が do_remount_sb() にアクセスできるようにする

スーパーブロック レベルの再マウントは、現在、グローバル CAP_SYS_ADMIN に制限されており、アンマウント時にルート マウントを読み取り専用に変更するパスも同様です。これらの権限チェックの両方を緩めて、ファイルシステムを最初にマウントしたユーザーに対して特権が付与されている任意の名前空間で CAP_SYS_ADMIN も許可します。

関連情報