This is response is kind of ridiculously delayed; vacation and a couple other things interfered!: On Wed, Aug 05, 2015 at 11:28:55AM -0500, Eric W. Biederman wrote: > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> writes: > > > On Tue, Aug 04, 2015 at 05:58:59PM -0500, Eric W. Biederman wrote: > >> > >> 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.... > > Not particularly when the whole point is to start with a bind mount, do > something trick and then have access to the whole filesystem instead of > just the part of the filesystem exposed by the bind mount. > > If you control the filesystem you already have access to the entire > filesystem, so you don't need to do something trick. I thought there was also a concern about impact on the sanity of the system as a whole beyond just the contents of one filesystem: e.g. you don't want an unprivileged user to be able to create an unmountable mountpoint. > That something tricky is a well placed rename that borks the tree > structure and causes .. to never see the subdirectory that is the root > of the bind mount. > > >> 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. > > Thanks. > > The file handle reconstitution code can certainly be affected by all of > this. Given that it is an failure if reconnect_path can't reconnect the > path of a file handle. I think it can reasonably considered an error in > all cases if that path is outside of an exported bind mount, but I don't > know that area particularly well. The solution might just be don't > export file handles from bind mounts. I don't think there's any new cause for concern here. I'd quibble with the language "don't export filehandles", *if* by that you mean "don't tell allow anyone to know filehandles". They're guessable, so keeping them secret doesn't guarantee much security. The dangerous operation is open_by_handle, and people need to understand that if you allow someone to call that then you're effectively giving access to the whole filesystem. That's always been true. (We don't really have an efficient way to determine if a non-directory is in a given subtree anyway.) Such filehandle-guessing attacks on NFS have long been well-understood. NOSUBTREECHECK can prevent them but causes other problems, so isn't the default. So the basic rule I think is "don't allow lookup-by-filehandle (or NFS export) on part of a filesystem unless you'd be willing to allow it on the whole thing". --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
