Control: reassign -1 manpages-dev On Tue, 2016-09-27 at 07:10 +0200, g1 wrote: > Source: linux > Severity: important > Tags: upstream > > > > > From the mount(2) man page: > > MS_BIND (Linux 2.4 onward) > Perform a bind mount, making a file or a directory subtree visible at > another point within a filesystem. Bind mounts may cross filesystem > boundaries and span chroot(2) jails. The filesystemtype and data > arguments are ignored. Up until Linux 2.6.26, mountflags was also > ignored (the bind mount has the same mount options as the underlying > mount point). > > Apparently, this applies to recent kernels too (at least 3.16). > > Silently ignoring user-specified flags can open security holes, e.g. when > a sysadm bind-mounts a filesystem for use by a containter, thinking the mount > will be read-only: > > # mount -o bind,ro /usr /containers/X/usr > > Despite mount returning successfully, container X has /usr mounted > read/write, and root inside the container can easily corrupt/subvert > the host system. > > Please keep in mind that recent versions of mount(1) work around the bug, by > calling mount() twice (once with the "bind" flag, then with the other flags), > but other applications calling mount() directly are usually affected.
This is a documentation error. The behaviour matches what was intended: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2e4b7fcd926006531935a4c79a5e9349fe51125b and is unlikely to be changed as it would probably break some applications. Ben. -- Ben Hutchings If the facts do not conform to your theory, they must be disposed of.
signature.asc
Description: This is a digitally signed message part
