rootfs exposure in /proc/mounts

Maybe I do oversee the obious but:

can somebody please explain why rootfs is exposed in /proc/mounts (I do mean the "rootfs / rootfs rw 0 0" entry) and if there is a good reason for the exposure?

Andreas Steinmetz

Mostly the fact that it _is_ mounted and special-casing its removal from /proc/mounts is more PITA than it's worth.

Acceptable but somewhat sad as it confuses e.g. "umount -avt noproc" which is somewhat standard in shutdown/reboot scripts (using a softlink from /etc/mtab to /proc/mounts).

Bug 1 - don't softlink directly to /proc/mounts :) embedded guys typically do this, and you see why it bites you in the ass :)

Bug 2 - "noproc" clearly does not avoid ramfs mounts, which is rootfs's filesystem type. And more and more ramfs filesystems will be appearing, so that should be taken into consideration.

Sounds like userspace slackness to me, and nothing that the kernel guys need to worry about...

Jeff

Only if there's another method to retrieve all filesystems mounted from userspace from the kernel. Though this may not be your view of things it is the only way to ensure that one gets a valid mount list. And as /proc/mounts is an interface to userspace it is my opinion that in kernel private mounts that can't be modified from userspace don't need to be listed there. Not my decision, anyway.

Jeff Garzik wrote:
[...]

Jeff, this remembers me on some discussion on LKML we had almost exactly 2 years ago (look for the thread starting with Message-ID [email protected])

Do you remember?

My opinion on this issue is still the same:

- Not only "embedded guys" symlink /etc/mtab to /proc/mounts! We do this for years now on our diskless workstations, because here our root-fs (and therefore /etc) is mounted readonly and so there is no way to update a _regular_ "/etc/mtab" file on a running system.

- /etc should contain only static configuration information. The table of mounted filesystems is not this kind of data. It's state information and should live somewhere else.

- the table of mounted filesystems is information which the kernel must have, anyway. Why maintain a separate file in userspace?

Comments?

- Andreas

Andreas Haumer                     | mailto:[email protected]
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71

Hi !

I remember this discussion too, and am also used to symlink mtab to /proc/mounts. But I also remember some people stating that /proc/mounts doesn't contain all information (some mount flags, nfs options ...) which may be needed for a mount -o remount, while mtab contains them.

I too agree that it's non-sense to have both mtab and /proc/mounts. If mounts isn't usable, why keep it ? At the moment, the only reason why I would abandon this symlink would be that mounts be removed from /proc entirely ! And I also agree that mtab shouldn't be under /etc (this is the only file that needs to be written to). At least, it should be moved to /var/state or something like that, provided it's available early in the boot stage, but this issue is not a kernel one anyway.

But at this time, I still think that a symlink to /proc/mounts is the safest solution in embedded or diskless situations, because even if we cannot update it for the very first mounts, at least it will be correct when /proc is mounted.

May be we should just accept this case as a common one, and update tools (mount, umount, df, ?) to be able to use both mtab and /proc/mounts, and simply ignore any rootfs entry.

Just my 0.02 euros.
Willy

symlinks directly to /proc/mounts is fine with me -- just don't expect any sympathy when userspace tools don't handle things like $subject. :) The answer will be "fix the userspace tools" not "add special case code to the kernel" :)

Jeff

well, better link to /proc/self/mounts directly, that's where /proc/mounts links to. That's another reason why the /etc/mtab-concept is broken:
you might have very different mounts in different processes.

I was just looking at these things I found few more such files in /etc. Like /etc/adjtime, /etc/mrtg/<something> and /etc/.aumixrc. I consider all of these user-space bugs. There are also /etc/passwd and /etc/shadow which will be written to if you are changing passwords while not using something like NIS. This is, in a sense, a harder case but one can live with that.

Michal

You can ?? apart from chroot that can make things interesting how do you do this?

clone(..., CLONE_NEWNS, ...)

After that subsequent namespace operations will only affect your process and it's child processes.

Cool.

Question: if those processes mount something and then exit, does that something get unmounted automatically or is this a mount point leak?

Rob

http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad, 
CmdrTaco, liquid nitrogen ice cream, and caffienated jello.  Well why not?

There seems to be two types of information in mtab, which is missing in /proc/mounts. First of all the first field of mtab is not always the name of a blockdevice. If it is a bindmount, this field will contain the name of the directory rather than the device, however this confuses some startupscripts, so having the device here might actually be better.

If the mount was done using the loop option, this field will contain the name of the backing file rather than the name of the loopback device. In the output from df, the name of the backing file will be more informative than the name of the loopback device, so I don't want to change that. But since a loopback device can also be mounted by manually using the losetup command, I would prefer another way to get the name of the backing file, that will work in both cases.

The options available in mtab but not in /proc/mounts, I would like to add to /proc/mounts. This could just be a string writable by the mount program. I don't think this should be anything fancy, just that any write to /proc/mounts should find the coresponding mount and update the string.

If the /etc/mtab file should exist at all it should at least be on a ramfs so we won't have to have the root mounted readwrite to update it. I have moved by mtab file to /etc/mtab.d/mtab and mount a ramfs on /etc/mtab.d. On boot I first mount /proc and /etc/mtab.d, then I create the mtab file from /proc/mounts. This is not an optimal solution, but I think it works better than having mtab on the root fs.

The optimal solution of the problem will include an update of the tools, and probably also the kernel.

Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:[email protected]
Don't do this at home kids: touch -- -rf

Both namespaces and vfsmounts are refcounted and garbage-collected if their useage counts hits zero, so there will be no leak.