☰

Почему внутри пространства имен пользователя мне не разрешено перемонтировать смонтированную мной файловую систему?

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, как и путь для изменения монтирования корня на чтение только при umount. Ослабьте обе эти проверки разрешений, чтобы также разрешить CAP_SYS_ADMIN в любом пространстве имен, которое является привилегированным по отношению к пользователям, которые изначально смонтировали файловую систему.

Связанный контент