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