[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

From: Goswin von Brederlow
Subject: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for
Date: Fri, 20 Jan 2012 08:42:26 +0100
User-agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE)

Henrique de Moraes Holschuh <address@hidden> writes:

> 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.

But isn't the rootfs out of reach because the initramfs "chroots" to the
real root and starts /sbin/init? Back when pivot_root was used that
was combined with an actual call to chroot. Before run-init combined the

I'm not realy disagreeing with you but argue that the duplicate rootfs
entry is not visible to the namespace.

Same with later chroots:

address@hidden:~/chroot% sudo chroot . df           
df: `/sys': No such file or directory
df: `/dev': No such file or directory
df: `/dev/pts': No such file or directory
df: `/run': No such file or directory
df: `/tmp': No such file or directory
df: `/usr': No such file or directory
df: `/var': No such file or directory
df: `/home': No such file or directory
df: `/var/lib/nfs/rpc_pipefs': No such file or directory
df: `/sys/fs/fuse/connections': No such file or directory
Filesystem         1K-blocks  Used Available Use% Mounted on
rootfs               1789128  1808   1787320   1% /
/dev/mapper/r-root   1789128  1808   1787320   1% /
tmpfs                1789128  1808   1787320   1% /

What it should show is only the last entry, the tmpfs the chroot is
on. All other entries are not visible to the processes inside the

Note that in a chroot any mountpoints inside the chroot have their
prefix removed (/home/mrvn/chroot becomes /) while others are left as
is. That is wrong too IMHO. The filesystem the chroots / is on should
become / even if the chroot is a directory instead of a mountpoint and
entries outside the chroot should not be listed at all.


reply via email to

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