On Tue, Aug 04, 2015 at 05:58:59PM -0500, Eric W. Biederman wrote: > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> writes: > > > 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. > > No problem. The basic question is: can 2Billion renames be performed on > the same filesystem in less time than a single path lookup? Allowing > the use of a 32bit counter. Certainly if you have control over an NFS or FUSE server then you can arrange for that to happen--just delay the lookup until you've processed enough renames. I don't know if that's interesting.... > If you could look up thread and tell me what you think of the issue with > file handle to dentry conversion and bind mounts I would be appreciate. OK, I see your comments in "[PATCH review 0/6] Bind mount escape fixes", I'm not sure I understand yet, I'll take a closer look. --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
