Jeff Layton <jlayton@xxxxxxxxxx> writes: > 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? For myself I start with the simple fact that the code has worked the way it currently does since around linux 0.99. We have to be very careful if we change this to avoid breaking existing applications. So if we change the existing behaviour it must be done in such a way that legitimate applications do not break. Eric -- 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
