Henrique de Moraes Holschuh <h...@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.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zkdilsm8.fsf@frosties.localnet
