On Thu, Aug 22, 2013 at 12:23 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Aug 22, 2013 at 12:05 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> >> Does this work for the procfs case? As far as I understand it (which >> isn't saying much), it goes through the symlink-following path. > > Right. The /proc case is still separate, and we really should do > something about that too. But again, I don't think I_LINKABLE is the > thing to use there either. We probably should tighten up the magic > /proc follow-link a lot. > >> What if we added another field to struct nameidata that's indicates >> what restrictions need to be enforced when following magical symlinks >> and then enforcing them when nd_jump_link gets used. (There are only >> two of these, both in procfs.) > > Yes, I think that might be just the kind of thing to do. Except some > tightening could well be quite regardless of any extra flags. > 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 might be a lot simpler to rig up nd_jump_link to immediately terminate lookup and let the callers (or the outer level of lookup) deal with it. That way the checks could be (more) easily unified with AT_EMPTY_PATH. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- 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
