On Thu, Aug 22, 2013 at 1:15 PM, Willy Tarreau <w...@1wt.eu> wrote: > On Thu, Aug 22, 2013 at 01:10:43PM -0700, Andy Lutomirski wrote: >> What's the point of nd_jump_link anyway? The only way I can think of >> for a magic symlink in /proc to point to another symlink is to open a >> symlink with O_PATH | O_NOFOLLOW. Actually trying to use the >> resulting link in /proc results in -ELOOP. (Even just trying to open >> a normal symlink with O_NOFOLLOW and without O_PATH results in >> -ELOOP.) > > It's not only that, it also supports sockets and pipes that you can access > via /proc/pid/fd and not via a real symlink which would try to open eg > "pipe:[23456]" instead of the real file. So you can't get rid of it > without breaking existing apps (starting with your shell for which > /dev/stdin is a link to /proc/self/fd/0 for example). >
Let me rephrase that: why do we allow these types of lookup to recurse like normal symlinks? I'm proposing that these links immediately terminate lookup and return back to user_path_at_empty, which can, in turn, do an extra check to see if the inode that was found is one of these magic inodes (or checks to see if nd_jump_link was called). user_path_at_empty could then enforce LOOKUP_EMPTY-list restrictions (or the caller could). --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
