The /etc/mtab vs. /proc/mounts Issue
Overview
Linux systems use two different mechanisms to keep track of mounted
filesystem. One is implemented in the kernel and exposes this
information to the user-space via /proc/mounts. The other
approach is to let the bookkeeping be done in user-space by the
mount utility using a separate file, namely /etc/mtab.
While the user-space approach means keeping redundant information
around that can become inconsistent, the kernel-space approach suffers
from certain implementation deficiencies that prevent it from
providing all the information to user-space. Even worse, the
implementation in the Linux 2.2.x kernels performs only sloppy
boundary checking and can corrupt kernel memory.
We therefore propose to fix the Linux kernel implementation of
/proc/mounts and get rid of /etc/mtab (or replace it
with a symlink to /proc/mounts) so that all information about
mounted filesystems is provided by the kernel itself.
Click here to go to the end of the page to get
the patches that already exist and to view our proposed plan to sort
things out. (Or keep on reading for a more in-depth discussion of this
issue...)
Defining the Problem
Unfortunately, each of the two mechanisms discussed in the overview
has its deficiencies and cannot be used as a general purpose solution.
What's Wrong With /proc/mounts?
The kernel-space mechanism has the following deficiencies:
-
On Linux 2.2.x kernels, this mechanism performs sloppy bounds
checking and can corrupt kernel memory. This means that you are
likely to get a kernel panic shortly after. In certain situations,
this bug can be triggered off without any malicious intentions in
mind. (We have successfully done so on Linux box running kernel 2.2.17.)
-
The listing of mounted filesystems might be incomplete since the size
of /proc/mounts is limited to 1 page. (On the IA32 platform this means
4kb). -- Using an automounter in a networked environment will easily
get you beyond this 4kb limit.
-
/proc/mounts does not show all mount options: The current
implementation does not list the options usrquota and
grpquota. Furthermore, it is inconsistent with the
mount utility as far as the naming of some NFS options with
the new NFSV3 code (will appear in 2.2.18) is concerned.
What's Wrong with /etc/mtab?
The approach taken by the mount utility that is part of the
util-linux package has some deficiencies too:
-
The information is redundant. Since the kernel has to keep
track of mounted filesystems anyway, duplicating this information in
/etc/mtab is redundant. Even worse, this redundancy can lead to
inconsitency and errorneous system behavior.
-
Having /etc/mtab can cause problems on some setups. As an
example, think of a system that (for some reason or another) should
mount its root-filesystem readonly.
Getting Things Right
We suggest the following plan to get this issue sorted out:
-
Step 1 (Done): Backport fs/super.c:get_filesystem_info from Linux
2.4.x. This makes at least the bounds-checking in this function
bullet-proof. Get this patch for
Linux 2.2.17 or this patch for
Linux 2.2.18pre17.
-
Step 2 (Todo): Get mount-options right. Patch
fs/super.c:get_filesystem_info so that all mount options are in sync
with what mount expects on a remount. Make sure that the
quota options show up, too. This fix should go in the 2.2.x as well as
in the 2.4.x kernel sources. We could come up with a patch for this in
relatively short time.
-
Step 3 (Todo): Remove the 1 page limit for /proc/mounts.
Finally, get rid of the 4kb size limit for /proc/mounts that is caused
by using convenience functions provided by the procfs
implementation. This fix should go into 2.4.x (maybe not 2.4.0). We
could come up with a patch for this.
