GNU bug report logs - #10363
/etc/mtab -> /proc/mounts symlink affects df(1) output for /

Previous Next

Full log

View this message in rfc822 format

From: Goswin von Brederlow <goswin-v-b <at> web.de>
To: Henrique de Moraes Holschuh <hmh <at> debian.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, Alan Curry <pacman-cu <at> kosh.dhis.org>, Goswin von Brederlow <goswin-v-b <at> web.de>, 653073 <at> bugs.debian.org, debian-devel <at> lists.debian.org, 10363 <at> debbugs.gnu.org, jidanni <at> jidanni.org, rleigh <at> codelibre.net
Subject: bug#10363: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for
Date: Fri, 20 Jan 2012 08:50:55 +0100

Henrique de Moraes Holschuh <hmh <at> debian.org> writes:

> On Thu, 19 Jan 2012, Paul Eggert wrote:
>> On 01/19/12 07:29, Henrique de Moraes Holschuh wrote:
>> > Note: there is no reason why the kernel could not return the mount
>> > information with shadowed paths removed in a separate procfs node, as
>> > that would cause no security/troubleshooting problems.
>> 
>> That's what I was thinking of, and it'd be a much better fix,
>> as it would fix things for all applications.
>> 
>> The current approach expects all app developers to modify
>> their applications in order to deal with a feature that app
>> developers typically don't know about and don't understand;
>> this isn't a good way to introduce a new feature.
>
> On the app side, I will tell you what you're likely to get back from the
> crowd on LKML:  write a proper BSD/MIT/LGPL library so that people don't
> have to reinvent the wheel, and fix it in userspace.  It gets worse: such
> library interface already exists, in the form of getmntent, setmntent,
> addmntent, endmntent, hasmntopt, getmntent_r.  So they will tell you to fix
> it in glibc.

How do you decide which of two conflicting entries is real? Since mount
--move does not change the order of entries you can not just pick the
last one.

For example which entry is the right one with an output like this:

tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=357828k,mode=755 0 0
tmpfs /run tmpfs rw,suid,exec,relatime,size=357828k,mode=755 0 0

I don't think this can be fixed in userspace alone. At a minimum the
kernel has to keep entries in order of visibility, i.e. the later
entries always shadow earlier entries. Which means that on mount --move
the kernel has to move the entry in /proc/mounts up or down as needed.

MfG
        Goswin

PS: I think you can also mount something below an already shadowed entry
(if you have a shell with cwd in the shadowed one) and it would show up
in the wrong spot in /proc/mounts.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.