Bind mounting source to itself

bind-mountfilesystemsmount

What does mount --bind /dir1 /dir1 do? I've read https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt however it doesn't give a clear explanation. Looks like it is valid not only for directories, but also for files.

Best Answer

This works exactly the same as the general case mount --bind /dir1 /dir2. All you need to know about the special case is that it is well defined and does not recurse infinitely.

(For example, files can be self-bind mounted because files can be bind-mounted).

The special case is less pointless than it first sounds, for two reasons.

1. You can set bind mount options, e.g. to limit possible operations

After this call the same contents are accessible in two places. One can also remount a single file (on a single file). It's also possible to use the bind mount to create a mountpoint from a regular directory, for example:
      mount --bind foo foo
The bind mount call attaches only (part of) a single filesystem, not possible submounts. The entire file hierarchy including submounts is attached a second place by using:
      mount --rbind olddir newdir
Note that the filesystem mount options will remain the same as those on the original mount point.

mount(8) since v2.27 allows to change the mount options by passing the relevant options along with --bind. For example:
      mount -o bind,ro foo foo
This feature is not supported by the Linux kernel; it is implemented in userspace by an additional mount(2) remounting system call. This solution is not atomic.

The alternative (classic) way to create a read-only bind mount is to use the remount operation, for example:
      mount --bind olddir newdir
      mount -o remount,bind,ro olddir newdir
Note that a read-only bind will create a read-only mountpoint (VFS entry), but the original filesystem superblock will still be writable, meaning that the olddir will be writable, but the newdir will be read-only.

It's also possible to change nosuid, nodev, noexec, noatime, nodiratime and relatime VFS entry flags by "remount,bind" operation. It's impossible to change mount options recursively (for example with -o rbind,ro).

Another use of mount options is to set the "propagation flags". These are specifically what sharedsubtree.txt explains. They can definitely be confusing. They're also outlined in man mount.

I only have one tip to offer: The doc claims shared subtrees were needed in order to propagate mounts of removable devices into a "slave" mount namespace. However a more critical motivation is to be able to unmount your removable device, after you've started a sandboxed process in a "slave" mount namespace.

2. It creates a boundary that files cannot be moved or linked across

Apparently this is desired partly in order to avoid bypassing the limitations imposed above, and partly because hardlinks can be really horrible for security and it could be useful to restrict them a bit.

UPDATE 2016-07-20:

The following are true for 4.5 kernels, but not true for 4.3 kernels (This is wrong. See update #2 below):

The kernel has two flags that control read-only:

The MS_READONLY: Indicating whether the mount is read-only
The MNT_READONLY: Indicating whether the "user" wants it read-only

On a 4.5 kernel, doing a mount -o bind,ro will actually do the trick. For example, this:

# mkdir /tmp/test
# mkdir /tmp/test/a /tmp/test/b
# mount -t tmpfs none /tmp/test/a
# mkdir /tmp/test/a/d
# mount -o bind,ro /tmp/test/a/d /tmp/test/b

will create a read-only bind mount of /tmp/test/a/d to /tmp/test/b, which will be visible in /proc/mounts as:

none /tmp/test/a tmpfs rw,relatime 0 0
none /tmp/test/b tmpfs ro,relatime 0 0

A more detailed view is visible in /proc/self/mountinfo, which takes into consideration the user view (namespace). The relevant lines will be these:

363 74 0:49 / /tmp/test/a rw,relatime shared:273 - tmpfs none rw
368 74 0:49 /d /tmp/test/b ro,relatime shared:273 - tmpfs none rw

Where on the second line, you can see that it says both ro (MNT_READONLY) and rw (!MS_READONLY).

The end result is this:

# echo a > /tmp/test/a/d/f
# echo a > /tmp/test/b/f
-su: /tmp/test/b/f: Read-only file system

UPDATE 2016-07-20 #2:

A bit more digging into this shows that the behavior in fact depends on the version of libmount which is part of util-linux. Support for this was added with this commit and was released with version 2.27:

commit 9ac77b8a78452eab0612523d27fee52159f5016a
Author: Karel Zak 
Date:   Mon Aug 17 11:54:26 2015 +0200

    libmount: add support for "bind,ro"

    Now it's necessary t use two mount(8) calls to create a read-only
    mount:

      mount /foo /bar -o bind
      mount /bar -o remount,ro,bind

    This patch allows to specify "bind,ro" and the remount is done
    automatically by libmount by additional mount(2) syscall. It's not
    atomic of course.

    Signed-off-by: Karel Zak

which also provides the workaround. The behavior can be seen using strace on an older and a newer mount:

Old:

mount("/tmp/test/a/d", "/tmp/test/b", 0x222e240, MS_MGC_VAL|MS_RDONLY|MS_BIND, NULL) = 0 <0.000681>

New:

mount("/tmp/test/a/d", "/tmp/test/b", 0x1a8ee90, MS_MGC_VAL|MS_RDONLY|MS_BIND, NULL) = 0 <0.011492>
mount("none", "/tmp/test/b", NULL, MS_RDONLY|MS_REMOUNT|MS_BIND, NULL) = 0 <0.006281>

Conclusion:

To achieve the desired result one needs to run two commands (as @Thomas already said):

mount SRC DST -o bind
mount DST -o remount,ro,bind

Newer versions of mount (util-linux >=2.27) do this automatically when one runs

mount SRC DST -o bind,ro

Debian – bind mounts by systemd don’t magically work with systemd-tmpfiles

bind is unreliable when defined in fstab on a system with systemd. Systemd parses the fstab and tries to work out what order to mount and bind things in. From my own experience it gets this wrong 100% of the time. Best option is to move all you binds out of fstab and make you own xxx.mount system files for systemd. That was you gain controo over the order etc.