> For /proc/mounts, one could argue that the admin might want to see everything, > but then that's not actually true even today because /proc/mounts doesn't > show lazyily unmounted stuff or mounts from other namespaces, so that > everything is quite relative. The current state is not good either > The getcwd() case is even stronger as the "see everything" argument makes even > less sense there. I really can't see why the kernel should return processes > fake pathnames. The process is explicitly asking for the current pathname to > the working directory, it doesn't want to know what the pathname was at some > previous point in time. Can you prove no existing application on the planet relies on the existing behaviour ? Actually more limited but sane as a test would be "Can you prove that the glibc behaviour visible to applications does not change" > Actually, no. We could live fine with leaving getcwd() and /proc/mounts as > ambiguous / weird / broken as they are right now. All it would take would be > to reambiguate the result of the unambiguous __d_path(), which is really > easy. Everything that cares about real pathnames would use the unambiguous > version while the legacy interfaces would use the ambiguous version. But that > really wouldn't make sense. I disagree - firstly because of not breaking stuff, and secondly because it separates two discussions - merging AppArmor being one of them , and the correct behaviour for getcwd & /proc/mounts being the other. > > Ok, providing the "real" root sees them all it isn't so bad, but to > > assume you can filter based upon what the task can see is dodgy as an > > assumption. > > Why? Because the viewing apparatus on the other side of the monitor is not operating in current directories/contexts. Alan - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
