Re: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for
Goswin von Brederlow goswin-...@web.de writes: 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. You can get such a view from /proc/self/mountinfo. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- 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/m2pqee8w9s@igel.home
Re: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for
On Fri, 20 Jan 2012, Goswin von Brederlow wrote: Henrique de Moraes Holschuh h...@debian.org writes: 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. ... 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. That's what I meant with I don't think this is quite correct right now. I'm not realy disagreeing with you but argue that the duplicate rootfs entry is not visible to the namespace. I am not sure how /proc/mounts and friends should play with chroot(). I suppose it depends on whether one can actually reach that path somehow. If it is forever unacessible, IMO it is effectively outside the namespace and I believe it should not be visible. But that's where I reach the limits of my knowledge, and I can't really argue about it. 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. I think you're correct in this. 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. I also think you're correct here, but as I said, chroot() is tricky, and I am wary of arguing too much about it without strong knowledge about the nuances, which I don't have. Maybe this thread really ought to move to linux-fsdevel or LKML? -- 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 -- 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/20120120174128.gb18...@khazad-dum.debian.net
Re: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for
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. 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/877h0o9fr1.fsf@frosties.localnet
Re: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for
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. -- 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 -- 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/20120119112300.ga20...@khazad-dum.debian.net
Re: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for
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% / tmpfs1789128 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
Re: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for
Alan Curry pacman...@kosh.dhis.org writes: jida...@jidanni.org writes: Filesystem 1K-blocksUsed Available Use% Mounted on rootfs 1071468 287940 729100 29% / /dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78 1071468 287940 729100 29% / (I'm replying only on the issue of the duplicate mount point. Someone else can tackle the long ugly name.) The one with rootfs as its device is the initramfs which you automatically get with all recent kernels. Even if you aren't using an initramfs, there's an empty one built into the kernel which gets mounted as the first root filesystem. The real root gets mounted on top of that. So this is a special case of a general problem with no easy solution: What should df do when 2 filesystems are mounted at the same location? It can't easily give correct information for both of them, since the later mount obscures the earlier mount from view. The problem also exists in a larger extend with chroots. There will be lots of entries from outside the chroot that are inaccessible to a df running inside the chroot. What df should do is automatically skip the entries that are obscured or generally inaccessible. Unfortunately the kernel does not (re)sort the entries correctly following a mount --move call: rootfs / rootfs rw 0 0 none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 none /proc proc rw,nosuid,nodev,noexec,relatime 0 0 none /dev devtmpfs rw,relatime,size=491516k,nr_inodes=122879,mode=755 0 0 none /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 /dev/mapper/s-root / ext3 ro,relatime,errors=remount-ro,data=ordered 0 0 tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,mode=755 0 0 ... Going by that list the /dev/mapper/s-root filesystems obscures the rootfs, /sys, /proc, /dev and /dev/pts. In reality though only the rootfs is obscured because the rest was moved prior to the initramfs switching / around. What the kernel should do is move the relevant entries so they appear below the filesystem they are moved to (and before any that do obscure them, moving them to the bottom isn't always the right solution). So at the moment is a bit of a guess which entries are real and which are obscured. The best you can do is check that each entry is actually a mountpoint and guess that the last of identical mountpoints is the right one. If there's a way for df to get the correct information for the lower mount, I don't know what it would be. If you have a process with a leftover cwd or open fd in the obscured filesystem, you can use that. But generally you won't. There afaik isn't and there should not be a way to do so. But maybe we could do better than reporting incorrectly that the lower mount has size and usage identical to the upper mount! At least df could print a warning at the end if it has seen any duplicate entries. Perhaps there is some way it could figure out which one is on top, and print a bunch of question marks as the lower mount's statistics. Maybe compare the major/minor of the device node with statfs() output. If df is running as root, it might be able to unshare(2) the mount namespace, unmount the upper level, and then statfs the mount point again to get the correct results for the lower level. That won't work in all cases (even in a private namespace you can't unmount the filesystem containing your own cwd) and it does nothing for you if you're not root, but still... it would be a cool bonus in the cases where it does work. As a special case, rootfs should probably be excluded from the default listing, since the initramfs is not very interesting most of the time. It could still be shown with the -a option, although it would always have the wrong statistics. Or if you really want to be impressive, default to showing the initramfs if and only if it is the only thing mounted on / - so you can run df within the initramfs before the real root is mounted and get the right result. What if you only have a rootfs? Imho the /proc/mounts file should only contain entries visible in the processes mount namespace. So for normal systems the rootfs shouldn't appear and in chroots the list should be even shorter. Or... (brace yourself for the most bold idea yet)... can you imagine a kernel interface that would *cleanly* give access to obscured mount points? I fear that would let too much information escape from/into the mount namesapces. But there could be a /proc/global-mounts or something that is only readable from the root namespace. Comments on any of the above? Do the BSDs have any bright ideas we can steal, or is their df as embarrassingly bad at handling obscured mount points as ours? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:
Re: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for
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. -- 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/4f170b94.3010...@cs.ucla.edu
Re: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for
So this is a special case of a general problem with no easy solution: What should df do when 2 filesystems are mounted at the same location? It can't easily give correct information for both of them, since the later mount obscures the earlier mount from view. It is a special case of an even more general problem, that mtab or /proc/self/mounts and therefore mount(8), df(1) etc. only represent the linear path where a filesystem was mounted at the time it was mounted, not the underlying tree structure. What happens with the following sequences, assuming / is the only mounted filesystem: mkdir /mnt/p1 mount /dev/sde1 /mnt/p1 mkdir /mnt/p1/p2 mount /dev/sdh1 /mnt/p1/p2 versus mkdir -p /mnt/p1/p2 mount /dev/sdh1 /mnt/p1/p2 mount /dev/sde1 /mnt/p1 not that that would be very useful, but in general it is possible. In the second case the filesystem on sdh1 is completely invisible, yet mtab and /proc/mounts in both cases contain something like /dev/sde1 /mnt/p1 ... /dev/sdh1 /mnt/p1/p2 ... only in different order: the last mounted filesystem comes last. This way df(1) should already be able to just hide any obscured filesystem: it could make two passes over the mount list, remembering every mount point and if a later mount point is equal or a parent of an earlier one (which can be determined by a simple string compare), mark the earlier one as invisible. Then in the second pass over the list output the remaining mounts. Remains the question whether this is correct in all cases and actually desirable behaviour. I think the latter is true, because df(1) output is just a snapshot of how the system looks like to a newly created process, and a newly created process can't access the obscured filesystems at all. (The fact that /proc/mounts is a symlink to /proc/self/mounts hints in the same direction.) If what's really wanted is the status of all mounted filesystems whether visible or not, I fear this can't be done without kernel help, because exactly by the snapshot as seen by a new process nature you don't get a handle to statfs() from the obscured parts. They can be found by looking in /sys/block or /proc/diskstats but there doesn't seem to be useful info, perhaps just another sysfs file containing the statfs() output would already suffice. Or perhaps just propose that one of the three nearly-identical /proc/self/mount* files get two additional columns with the info df(1) needs... Olaf -- 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/e1rgkih-00041l...@bigred.inka.de
Re: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for
jida...@jidanni.org writes: Filesystem 1K-blocksUsed Available Use% Mounted on rootfs 1071468 287940 729100 29% / /dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78 1071468 287940 729100 29% / (I'm replying only on the issue of the duplicate mount point. Someone else can tackle the long ugly name.) The one with rootfs as its device is the initramfs which you automatically get with all recent kernels. Even if you aren't using an initramfs, there's an empty one built into the kernel which gets mounted as the first root filesystem. The real root gets mounted on top of that. So this is a special case of a general problem with no easy solution: What should df do when 2 filesystems are mounted at the same location? It can't easily give correct information for both of them, since the later mount obscures the earlier mount from view. If there's a way for df to get the correct information for the lower mount, I don't know what it would be. If you have a process with a leftover cwd or open fd in the obscured filesystem, you can use that. But generally you won't. But maybe we could do better than reporting incorrectly that the lower mount has size and usage identical to the upper mount! At least df could print a warning at the end if it has seen any duplicate entries. Perhaps there is some way it could figure out which one is on top, and print a bunch of question marks as the lower mount's statistics. If df is running as root, it might be able to unshare(2) the mount namespace, unmount the upper level, and then statfs the mount point again to get the correct results for the lower level. That won't work in all cases (even in a private namespace you can't unmount the filesystem containing your own cwd) and it does nothing for you if you're not root, but still... it would be a cool bonus in the cases where it does work. As a special case, rootfs should probably be excluded from the default listing, since the initramfs is not very interesting most of the time. It could still be shown with the -a option, although it would always have the wrong statistics. Or if you really want to be impressive, default to showing the initramfs if and only if it is the only thing mounted on / - so you can run df within the initramfs before the real root is mounted and get the right result. Or... (brace yourself for the most bold idea yet)... can you imagine a kernel interface that would *cleanly* give access to obscured mount points? Comments on any of the above? Do the BSDs have any bright ideas we can steal, or is their df as embarrassingly bad at handling obscured mount points as ours? -- Alan Curry -- 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/20111226232705.29921.qm...@kosh.dhis.org
