Why can't you rename (or move) a mount point?

Question

I can move the parent directory of a mount point as follows:

$ mkdir -p f/mnt
$ bindfs --no-allow-other f/mnt f/mnt
$ mv f g
$

But I cannot rename the mount point itself:

$ mv g/mnt g/m
mv: cannot move 'g/mnt' to 'g/m': Device or resource busy

Is there a security, compatibility, or implementation reason for this distinction?

My kernel version is 4.17.19-200.fc28.x86_64.

Answer 1

Schily's answer about why this is not working is accurate.

However, you actually can move mount points themselves on Linux. Borrowing from the example in the question, the correct way to do this is:

mount --move g/mnt g/m

The target directory (in this case g/m) has to be a valid location for a mount point (the directory has to exist, etc) and you must be running with root privileges (or CAP_MOUNT), but otherwise there are essentially no restrictions.

This operation will update all kernel managed data structures referencing that mount point, including mount table entries (within the current mount namespace), open file descriptors, root and current working directories for running programs, and a few other things, so it is (reasonably) safe to do this on a mount point in active use.

The caveat is that anything which is running and uses paths instead of file descriptors may not properly handle it (for example, moving the root of your website this way will probably break the website, because most web servers don't keep open references to all the files for the site).

You may also find the pivot_root command interesting, it's a special case of moving a mount point (it swaps two mount points and updates the root and current working directory of everything on the system), and is used during startup on most modern Linux systems to switch from the initramfs to the real root filesystem.

Answer 2

You cannot rename the root directory of a filesystem and this is what you like to do.

If you NFS-mount the filesystem with the underlying mount point, you may be able to rename it as this allows you to see the uncovered mount point.

Background: if something is mounted to an entry in the filesystem, this hides the orignal file, but you would need to rename the original file. What you see is the root directory of the mounted filesytem and that cannot be renamed.

Answer 3

Yes: compatibility reasons which affect security.

This restriction was deliberately not removed, for a reason reported faithfully by LWN.net. Removing the restriction would create a security hole in some versions of fusermount. fusermount had been improved earlier by adding UMOUNT_NOFOLLOW, and this made it safe. However the old versions of fusermount were still widespread enough to be a concern.

See Mount point removal and renaming, LWN.net 2016.

As far as I can tell from the linked thread, patches 1-3 would have allowed moving a mount point. And then patch 4 was added to forbid it :-).

This is not complete proof. However it suggests the restriction in patch 4 was not due to internal implementation reasons. I also believe kernel developers would have mentioned, if they had any idea that user expectations would have been broken by allowing mount points to be moved.

@schily, however, points out there is something strange about allowing mount points to be moved (or unlinked). It appears that it was possible to allow rename() of a mount point. But only because it was interpreted as renaming the file underlying the mounted filesystem(s).

It would be a strange exception to the current rule, that rename(oldpath, newpath) requires that the oldpath and newpath are on the same filesystem. Otherwise it fails with EXDEV. (In fact they must be on the same mount of the filesystem).

I thought of one extra little strangeness under Linux. If you set the Linux "immutable bit" on the underlying file, I think the rename() should be denied. But if you inspect the immutable bit on the mount point, you will not see the immutable bit of the underlying file! I expect it works fine, it would just be rather annoying if you ever had to troubleshoot it.