Re: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for
On Fri, 20 Jan 2012, Goswin von Brederlow wrote:
> Henrique de Moraes Holschuh <hmh@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.
Yes, it would have to order in that way.
> 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.
I believe that's correct, and should be fixed.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: