| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CALCETrWivFAqiWAfAYzZ4fgKC87H+VhyOLrfb+ONCjMmqKG9eQ@mail.gmail.com> Date: Mon, 29 Sep 2014 16:45:42 -0700 From: Andy Lutomirski <luto@...capital.net> To: Linux FS Devel <linux-fsdevel@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Eric W. Biederman" <ebiederm@...ssion.com>, Al Viro <viro@...iv.linux.org.uk> Subject: Removing shared subtrees? As far as I know, shared subtrees in recursive bind mounts are a misfeature that existed for the sole purpose of allowing recursive binds + chroot to emulate mount namespaces. But we have mount namespaces, so what are they for? They're totally fsked up. For example, don't try this on a live system: # mount --make-rshared / # mount --rbind / /mnt # umount -l /mnt It will unmount *everything*. On Fedora, you don't even need the --make-rshared part. WTF? Can we just remove the feature entirely in linux-next and see if anyone complains? I'm all for propagation across mount namespaces, but I suspect that, at the very least, there is no legitimate reason whatsoever for mounts to propagate from a recursive bind mount back to the origin. IOW, can we kill shared mounts and just keep private and slave mounts? --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists