Henrique de Moraes Holschuh <h...@debian.org> writes:
> On Thu, 19 Jan 2012, Goswin von Brederlow wrote:
>> Paul Eggert <egg...@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.
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
two.
I'm not realy disagreeing with you but argue that the duplicate rootfs
entry is not visible to the namespace.
Same with later chroots:
mrvn@frosties:~/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
chroot.
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.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874nvqn7kt.fsf@frosties.localnet
