[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: Henrique de Moraes Holschuh
Subject: bug#10363: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for
Date: Thu, 19 Jan 2012 14:30:06 -0200
User-agent: Mutt/1.5.20 (2009-06-14)

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.

AFAIK, the kernel is not in any better position to remove shadowed paths
than userspace, both are perfectly capable of doing it.   Now, removing
paths that are outside of the current process scope (due to namespaces or
chroot or whatever), THAT is something only the kernel can do correctly...

  "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 via email to

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