On Mon, 23 Nov 2009 22:49:48 +0000 Jamie Lokier <jamie@xxxxxxxxxxxxx> wrote: > Jeff Layton wrote: > > > check_path_accessible seems pretty horrible. If a process is running > > > inside of a subdirectory it doesn't have permissions to access, say > > > a chroot, /proc/self/fd/XXX becomes completely unusable. > > > > > > > Hmm...I have this in there: > > > > + /* are we at global root or root of namespace? */ > > + if ((tdentry == root.dentry && vfsmnt == root.mnt) || > > + vfsmnt->mnt_parent == vfsmnt) > > + break; > > > > ...In the case of a chroot, wouldn't "current->fs->root" point to the > > root of the process' namespace? Or am I misunderstanding what > > current->fs actually represents? > > A process can run inside a subdirectory it doesn't have permissions to > access without that being a chroot. > Certainly. > It can also run inside a subdirectory that isn't accessible from it's > root, if that's how it was started - as well as having other > descriptors pointing to things outside its root. > Yes. > It can also be passed file descriptors from outside it's root while > it's running. > Yep. > Really, I think the /proc/PID/fd/N check should restrict the open to > the O_* limitations that were used to open fd N before, and not have > any connection to actual paths at the time of this check. > The big question with all of this is: Should a task have the ability to follow a /proc/pid symlink to a path that it wouldn't ordinarily be able to resolve with a path lookup. The concensus that I got from the bugtraq discussion was that it should not, and this patch is an attempt to prevent that. I take it from you and Eric's comments that you disagree? If so, what's your rationale for allowing a task to resolve this symlink when it wouldn't ordinarily be able to do so if it were a "normal" symlink? -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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