[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 13:29:24 -0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Thu, 19 Jan 2012, Henrique de Moraes Holschuh wrote:
> On Thu, 19 Jan 2012, Goswin von Brederlow wrote:
> > Paul Eggert <address@hidden> writes:
> > > On 01/18/12 06:25, Goswin von Brederlow wrote:
> > >> What df should do is automatically skip the entries that are obscured or
> > >> generally inaccessible.
> > >
> > > Isn't this missing some of the larger context?  df is just doing what
> > > lots of other programs do: finding out what file systems one has,
> > > and reporting statistics on them.  It sounds suboptimal to require
> > > the maintainers of all these programs (coreutils, nautilus, etc.)
> > > to rewrite their apps to deal with obscured entries.  Surely it would
> > > be better to have the kernel ordinarily return just the ordinary entries,
> > > and to return obscured entries only when they are specially requested.
> > > That way, this issue would be isolated to the few bits of code that really
> > > want to see obscured entries.
> > 
> > +1. Kernel knows best anyway.
> The kernel has to return all entries that are visible to the current
> namespace, otherwise you pretty much cannot know about the existence of
> shadowed entries in the first place, and that has all sort of nasty
> implications for security and troubleshooting.
> The kernel should NOT include entries that are out of reach due to
> namespaces or chrooting, but I don't think this is quite correct right now.
> If you don't want to show to the user shadowed entries, fix it in the
> UI, maybe write a nice LGPL lib and get the various GNU utils to use it
> to avoid duplicated effort...  or fix it in glibc, if applicable.  But
> /proc/mounts really has to return complete information.

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.  I do think
kernel people will tell you to fix that in userspace, though.

  "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]