Not sure wether we're affected by this one: Since 2.2 we have been doing a chroot check to see if it is appropriate to return a read or follow one of these magic symlinks. The chroot check was asking a question about the visibility of files to the calling process and it was actually checking the destination process, and not the files themselves. That test was clearly bogus. In my first pass through I simply fixed the test to check the visibility of the files themselves. That naive approach to fixing the permissions was too strict and resulted in cases where a task could not even see all of it's file descriptors. What has disturbed me about relaxing this check is that file descriptors are per-process private things, and they are occasionaly used a user space capability tokens. Looking a little farther into the symlink path on /proc I did find userid checks and a check for capability (CAP_DAC_OVERRIDE) so there were permissions checking this. But I was still concerned about privacy. Besides /proc there is only one other way to find out this kind of information, and that is ptrace. ptrace has been around for a long time and it has a well established security model. So after thinking about it I finally realized that the permission checks that make sense are the permission checks applied to ptrace_attach. The checks are simple per process, and won't cause nasty surprises for people coming from less capable unices. Unfortunately there is one case that the current ptrace_attach test does not cover: Zombies and kernel threads. Single stepping those kinds of processes is impossible. Being able to see which file descriptors are open on these tasks is important to lsof, fuser and friends. So for these special processes I made the rule you can't find out unless you have CAP_SYS_PTRACE. These proc permission checks should now conform to the principle of least surprise. As well as using much less code to implement :) Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Created attachment 104552 [details, diff] Patch in Git
hppa-sources: Bump to 2.6.19 or patch. mips-sources: Bump to 2.6.19 or patch. rsbac-sources: Bump to 2.6.19 or patch. systrace-sources: Bump to 2.6.19 or patch. usermode-sources: Bump to 2.6.19 or patch. xen-sources: Bump to 2.6.19 or patch.
hppa-sources-2.6.19.1 commited.
usermode-sources-2.6.18-r1 added.
rsbac-sources-2.6.19 is in cvs (~arch)
Waiting on Xen.
The patch listed here was actually included in 2.6.18, not 2.6.19. So >=xen-sources-2.6.18 is unaffected. I masked xen-sources-2.6.16 a couple days ago and will be removed soon.
