[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#10363: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /pro

From: Goswin von Brederlow
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
User-agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE)

Henrique de Moraes Holschuh <address@hidden> 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.


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]