[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.
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.
- bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for, Goswin von Brederlow, 2012/01/18
- bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for, Paul Eggert, 2012/01/18
- bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for, Goswin von Brederlow, 2012/01/19
- bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for, Henrique de Moraes Holschuh, 2012/01/19
- bug#10363: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for, Henrique de Moraes Holschuh, 2012/01/19
- bug#10363: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for, Paul Eggert, 2012/01/19
- bug#10363: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for, Henrique de Moraes Holschuh, 2012/01/19
- bug#10363: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for, Paul Eggert, 2012/01/19
- bug#10363: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for,
Goswin von Brederlow <=
- bug#10363: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for, Henrique de Moraes Holschuh, 2012/01/20
- bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for, Goswin von Brederlow, 2012/01/20
- bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for, Henrique de Moraes Holschuh, 2012/01/20
- Message not available
- bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for, Andreas Schwab, 2012/01/20