Bug#653073: 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: [Pkg-sysvinit-devel] Bug#653073: 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: On Thu, 19 Jan 2012, Paul Eggert wrote: On 01/19/12 07:29, Henrique de Moraes Holschuh wrote: 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. That's what I was thinking of, and it'd be a much better fix, as it would fix things for all applications. The current approach expects all app developers to modify their applications in order to deal with a feature that app developers typically don't know about and don't understand; this isn't a good way to introduce a new feature. On the app side, I will tell you what you're likely to get back from the crowd on LKML: write a proper BSD/MIT/LGPL library so that people don't have to reinvent the wheel, and fix it in userspace. It gets worse: such library interface already exists, in the form of getmntent, setmntent, addmntent, endmntent, hasmntopt, getmntent_r. So they will tell you to fix it in glibc. How do you decide which of two conflicting entries is real? Since mount --move does not change the order of entries you can not just pick the last one. For example which entry is the right one with an output like this: tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=357828k,mode=755 0 0 tmpfs /run tmpfs rw,suid,exec,relatime,size=357828k,mode=755 0 0 I don't think this can be fixed in userspace alone. At a minimum the kernel has to keep entries in order of visibility, i.e. the later entries always shadow earlier entries. Which means that on mount --move the kernel has to move the entry in /proc/mounts up or down as needed. Yes, it would have to order in that way. PS: I think you can also mount something below an already shadowed entry (if you have a shell with cwd in the shadowed one) and it would show up in the wrong spot in /proc/mounts. I believe that's correct, and should be fixed. -- 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for
Jon Dowland j...@debian.org writes: On Wed, Jan 18, 2012 at 03:25:05PM +0100, Goswin von Brederlow wrote: What df should do is automatically skip the entries that are obscured or generally inaccessible I disagree. It's quite conceivable for a user to accidentally mount two things over the same VFS path. When they do, they may rely on df(1)'s output to help them untangle the mess. If one of the two mounts is hidden, they may not be able to fathom what they did: worse, they might tug a disk with a mounted filesystem by accident, being unable to determine that it was mounted. -- Jon Dowland skip could also mean show -- instead of bogus numbers for the obscured filesystems. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: ~ Re: Bug#653073: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for
On Thu, Jan 19, 2012 at 10:55:43AM +0100, Goswin von Brederlow wrote: skip could also mean show -- instead of bogus numbers for the obscured filesystems. Much more preferable (to me) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: ~ Re: Bug#653073: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for
On Wed, Jan 18, 2012 at 04:51:12PM +, Roger Leigh wrote: Is this not a case of using the wrong tool for the job? The primary purpose of df is to show free space on mounted filesystems. This could be interpreted to be show free space on visible mounts. Possibly, but then I am certainly guilty of using df(1) for these purposes, and I know of many experienced sysadmins that are the same. I'd wager most google-able advice on the matter would suggest df(1). mount(8) and findmnt(8) [new, and very nice] are more appropriate for this task. Perhaps, but their manpage sections strongly imply they aren't as generally-useful/usable as df(1), to an ordinary user. (sysadmin tools? here be dragons!) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for
On Thu, 19 Jan 2012, Henrique de Moraes Holschuh wrote: 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. 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for
On 01/19/12 07:29, Henrique de Moraes Holschuh wrote: 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. That's what I was thinking of, and it'd be a much better fix, as it would fix things for all applications. The current approach expects all app developers to modify their applications in order to deal with a feature that app developers typically don't know about and don't understand; this isn't a good way to introduce a new feature. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for
On Thu, 19 Jan 2012, Paul Eggert wrote: On 01/19/12 07:29, Henrique de Moraes Holschuh wrote: 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. That's what I was thinking of, and it'd be a much better fix, as it would fix things for all applications. The current approach expects all app developers to modify their applications in order to deal with a feature that app developers typically don't know about and don't understand; this isn't a good way to introduce a new feature. On the app side, I will tell you what you're likely to get back from the crowd on LKML: write a proper BSD/MIT/LGPL library so that people don't have to reinvent the wheel, and fix it in userspace. It gets worse: such library interface already exists, in the form of getmntent, setmntent, addmntent, endmntent, hasmntopt, getmntent_r. So they will tell you to fix it in glibc. AFAIK, the kernel is not in any better position to remove shadowed paths than userspace, both are perfectly capable of doing it. Now, removing paths that are outside of the current process scope (due to namespaces or chroot or whatever), THAT is something only the kernel can do correctly... -- 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: bug#10363: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for
On 01/19/12 08:30, Henrique de Moraes Holschuh wrote: On the app side, I will tell you what you're likely to get back from the crowd on LKML: write a proper BSD/MIT/LGPL library This argument would have stronger force if there were real code in a real application, code that solved the overall problem -- code that we could read and run. I don't know of any such code. the kernel is not in any better position to remove shadowed paths than userspace, both are perfectly capable of doing it. This seems to contradict an earlier comment made by someone else, So at the moment is a bit of a guess which entries are real and which are obscured. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10363#53 I don't know who's right, nor do I understand what all the underlying issues are. I expect most other app developers are in a similar boat. It's not a good situation to be in. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: [Pkg-sysvinit-devel] Bug#653073: 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, Paul Eggert wrote: On 01/19/12 07:29, Henrique de Moraes Holschuh wrote: 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. That's what I was thinking of, and it'd be a much better fix, as it would fix things for all applications. The current approach expects all app developers to modify their applications in order to deal with a feature that app developers typically don't know about and don't understand; this isn't a good way to introduce a new feature. On the app side, I will tell you what you're likely to get back from the crowd on LKML: write a proper BSD/MIT/LGPL library so that people don't have to reinvent the wheel, and fix it in userspace. It gets worse: such library interface already exists, in the form of getmntent, setmntent, addmntent, endmntent, hasmntopt, getmntent_r. So they will tell you to fix it in glibc. How do you decide which of two conflicting entries is real? Since mount --move does not change the order of entries you can not just pick the last one. For example which entry is the right one with an output like this: tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=357828k,mode=755 0 0 tmpfs /run tmpfs rw,suid,exec,relatime,size=357828k,mode=755 0 0 I don't think this can be fixed in userspace alone. At a minimum the kernel has to keep entries in order of visibility, i.e. the later entries always shadow earlier entries. Which means that on mount --move the kernel has to move the entry in /proc/mounts up or down as needed. MfG Goswin PS: I think you can also mount something below an already shadowed entry (if you have a shell with cwd in the shadowed one) and it would show up in the wrong spot in /proc/mounts. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for
On Wed, Jan 18, 2012 at 03:25:05PM +0100, Goswin von Brederlow wrote: What df should do is automatically skip the entries that are obscured or generally inaccessible I disagree. It's quite conceivable for a user to accidentally mount two things over the same VFS path. When they do, they may rely on df(1)'s output to help them untangle the mess. If one of the two mounts is hidden, they may not be able to fathom what they did: worse, they might tug a disk with a mounted filesystem by accident, being unable to determine that it was mounted. -- Jon Dowland -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: bug#10363: /etc/mtab - /proc/mounts symlink affects df(1) output for
On Wed, Jan 18, 2012 at 04:03:04PM +, Jon Dowland wrote: On Wed, Jan 18, 2012 at 03:25:05PM +0100, Goswin von Brederlow wrote: What df should do is automatically skip the entries that are obscured or generally inaccessible I disagree. It's quite conceivable for a user to accidentally mount two things over the same VFS path. When they do, they may rely on df(1)'s output to help them untangle the mess. If one of the two mounts is hidden, they may not be able to fathom what they did: worse, they might tug a disk with a mounted filesystem by accident, being unable to determine that it was mounted. Is this not a case of using the wrong tool for the job? The primary purpose of df is to show free space on mounted filesystems. This could be interpreted to be show free space on visible mounts. mount(8) and findmnt(8) [new, and very nice] are more appropriate for this task. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653073: 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
