Detecting a mount point
Today, I just want to dispense the results of a tiny bit of research I did. May it be of some use to you :)
How to scan a directory tree
In the old days, the way to scan a directory tree was to
readdir the names in the directory,
lstat them, and then recursively do this for any directories you found. The reason you would use
lstat instead of
stat is that symlinks can point up in the tree, potentially creating loops. Directories cannot point up in the tree, because you can't hardlink them: the original prohibition on hard linking directories was implemented because it tricks programs into endless recursion.
That doesn't keep
bash from doing it the wrong way (
echo ** is a sure way to invoke the out-of-memory killer on my system, if I had the patience to wait for it, that is), but most programs working on directory trees (such as
tar) do get this right.
The two main cases where this is not enough are
-x options and Linux. First, many programs have an
--one-file-system option that instructs them not to cross filesystem boundaries. That way, you can use
tar --one-file-system to get a tar file of your root filesystem without also adding
/proc for example.
The way this was traditionally implemented is to stat the directory you want to recurse into and its parent directory, and see whether the
st_dev member matches. If it doesn't match, the subdirectory is on another filesystem, i.e. a mount point.
Unfortunately, this fails badly on Linux, for two reasons. The first is a bug -
st_dev values are not stable (most notably with NFS), that is, you might
stat a path, get a
st_dev value, and later
stat the same path again to get a different
st_dev value, even though nothing has changed. This can cause your tree walker to detect a filesystem crossing when there really isn't one.
The other reason is bind mounts - you can create a loop by bind mounting some directory into a subdirectory of itself:
mkdir subdir mount --bind . subdir ls subdir/subdir/subdir/subdir/...
This successfully confuses a lot of programs who otherwise get recursion right (or to put it differently, Linux bind mounts broke a lot of programs that worked properly for decades).
So how to avoid it?
The horrible way
One horrible way is to parse
/etc/mounts, the output of
mount, or some other source of mount points and compare the paths with the directory you want to enter, to see if it is a mount point.
This is horrible for so many reasons - comparing paths is hard (some of the components might be symlinks), and there are so many race conditions you can't check for - somebody could mount a new directory, an existing directory could be renamed, and so on.
I'd outright refuse to use this method, even if there was no other solution.
The tricky^Wtrivial way
Fortunately, there is a super-simple way of checking whether a directory is a mount point that is mostly race-free (and can be used for completely race-free scanning with some care) - by exploiting what some people consider a bug, but the Linux kernel developers fortunately consider a security feature: While a bind mount might refer to the same filesystem as its parent, it is still a security boundary for
rename and similar syscalls.
That means that you can't
link over mount point boundaries, even when source and destination are the same filesystem!
A practical way to exploit this is to do some illegal rename and then check the error return (
rename ("somepath/.", "somepath/subdir/.");
If this succeeds, you are in big trouble of course. So it will fail, but how exactly does it fail?
If it fails with
EXDEV, then somepath/subdir is a mount point. Otherwise (e.g.
EBUSY), it isn't. If you
chdir into the subdir before checking (or use the xxx
at functions), and use relative paths, then it is even race-free, i.e. this will reliably tell you whether the current directory is a mount point:
rename ("../.", ".");
Even if somebody mounts something over that directory shortly afterwards, your program can still continue to scan to underlying paths on the same filesystem.
Brilliant, isn't it? So what are the trade-offs? Everything has trade-offs, right?
Well, for one, this isn't exactly POSIX-specified behaviour. Bind mounts and other constructs where this problem happens aren't governed by POSIX anyway, and some OS might someday implement a similar construct and allow cross-mount-point renames. I don't know of any who do at the moment, and it would be dumb to do so, but then...
The bigger issue is that POSIX doesn't actually specify the order in which error conditions are checked. The above rename can fail for a number of reasons, and there is no guarantee that
EXDEV will be returned even for mount points - the kernel could simply refuse to use . as source path, regardless of destination. But currently, it is working, everywhere, and that's likely not going to change.
In any case, it's more portable and better than any other alternative I can think of.
Appendix: security boundary?
The reason why the
EXDEV error behaviour is not an accident but by design is that it is supposedly usable as a security boundary. As explained by Al Viro, this:
mount --bind /tmp /tmp
Gives you a /tmp directory that keeps people from linking from inside /tmp to the outside, and vice versa, which prevents some common exploits.
So this is a supported feature. Of course, there are bugs everywhere, so it might not always work, but that isn't news, is it?