On August 15, 2015 2:48:34 PM CDT, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >On Sat, Aug 15, 2015 at 12:36 PM, Linus Torvalds ><torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >> >> Can we really not validate ".." some clever way _without_ adding all >> those "mount escape" flags? And by "clever" I potentially mean "not >> clever" and in fact just fairly brute force. I'd almost prefer to >just >> walk the parent chains all the way to the root and validate the ".." >> that way.. > >For example: while it's true that walking a logn chain of parents (to >validate that we hit root etc) would be expensive, I don't think we'd >necessarily need to do it for the common case. > >For example, if out current "mnt->mnt_root" is a _real_ root (so >IS_ROOT() is true), then we know we're not in some possibly partial >bind mount, so we don't need to check anything else, and we can >happily move to the parent dentry *without* having to be particularly >careful. > >Otherwise we might need to walk the dentry parent chain to check that >yes, we will hit that mnt->mnt_root" entry, and that we're not >possibly escaping the bind mount. But even that walk is "just" >following a chain of pointers. It's not *that* expensive. > >I'd much rather make ".." more expensive, if it means that we don't >have to track the status of whether a mount has a potentially escaped >directory in it or not. Because I think we can avoid the costs for >traditional non-bind mounts. > >No? Yes we can compare s_root and mnt_root and only call is_subir if they don't match. At this point it is a matter of trade offs. If there is not an escape I do not expect my current implementation will have a measurable cost. And I don't expect there will be any escapes. That said if you and Al would be happy with what you are proposing I can easily implement it. My only concern at this point is that I know some containers run with a bind mount for their root directory so it might be a change with a measurable cost. At the same time shallow directory paths are the norm so I don't expect there to be much of a cost. 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
