[Pkg-sysvinit-devel] Bug#653073: Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for
Henrique de Moraes Holschuh
hmh at debian.org
Thu Jan 19 15:29:24 UTC 2012
On Thu, 19 Jan 2012, Henrique de Moraes Holschuh wrote:
> On Thu, 19 Jan 2012, Goswin von Brederlow wrote:
> > Paul Eggert <eggert at cs.ucla.edu> 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
More information about the Pkg-sysvinit-devel
mailing list