On Tue, Aug 04, 2015 at 12:41:32PM -0500, Eric W. Biederman wrote: > A pathname lookup taking 16 seconds seems absurd. But perhaps in the > worst case. > > The maximum length of a path that can be passed into path_lookup is > 4096. For a lookup to be problematic there must be at least as many > instances of .. as there are of any other path component. So each pair > of a minium length path element and a .. element must take at least 5 > bytes. Which in 4096 bytes leaves room for 819 path elements. If every > one of those 819 path components triggered a disk seek at 100 seeks per > second I could see a path name lookup potentially taking 8 seconds. A lookup on NFS while a server's rebooting or the network's flaky could take arbitrary long. Other network filesystems and fuse can have similar problems. Depending on threat model an attacker might have quite precise control over that timing. Disk filesystems could have all the same problems since there's no guarantee the underlying block device is really local. Even ignoring that, hardware can be slow or flaky. And couldn't an allocation in theory block for an arbitrary long time? Apologies for just dropping into the middle here! I haven't read the rest and don't have the context to know whether any of that's relevant. --b. -- 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
