☰

Warum darf ich ein bereits gemountetes Dateisystem innerhalb eines Benutzernamensraums nicht erneut mounten?

tag-icon • tag-icon linux mount namespace
Warum darf ich ein bereits gemountetes Dateisystem innerhalb eines Benutzernamensraums nicht erneut mounten?

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)
...

Das erneute Einhängen der Bindung funktioniert einwandfrei.

 # 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

Antwort1

Es wurde nicht implementiert. Es ist jedoch in der nächsten Version enthalten!

v4.18 enthält das folgende Commit. Es wird kein genauerer Grund dafür genannt, warum es zuvor nicht unterstützt wurde.

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

fs: Erlaube dem Superblock-Besitzer den Zugriff auf do_remount_sb()

Remounts auf Superblock-Ebene sind derzeit auf das globale CAP_SYS_ADMIN beschränkt, ebenso wie der Pfad zum Ändern des Root-Mounts auf Nur-Lesen bei Umount. Lockern Sie diese beiden Berechtigungsprüfungen, um auch CAP_SYS_ADMIN in jedem Namespace zuzulassen, der gegenüber den Benutzern privilegiert ist, die das Dateisystem ursprünglich gemountet haben.

verwandte Informationen