On Thu, Apr 11, 2024 at 12:34:52PM -0700, Linus Torvalds wrote: > On Thu, 11 Apr 2024 at 11:13, Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > So while I understand your motivation, I actually think it's actively > > wrong to special-case __O_TMPFILE, because it encourages a pattern > > that is bad. > > Just to clarify: I think the ns_capable() change is a good idea and > makes sense. The whole "limited to global root" makes no sense if the > file was opened within a namespace, and I think it always just came > from the better check not being obvious at the point where > AT_EMPTY_PATH was checked for. > > Similarly, while the FMODE_PATH test _looks_ very similar to an > O_TMPFILE check, I think it's fundamentally different in a conceptual > sense: not only is FMODE_PATH filesystem-agnostic, a FMODE_PATH file > is *only* useful as a pathname (ie no read/write semantics). But the annoying part imho is that we also allow stuff like fsetxattr() to work on O_PATH file descriptors. Something that I really dislike. > > And so if a FMODE_PATH file descriptor is passed in from the outside, > I feel like the "you cannot use this to create a path" is kind of a > fundamentally nonsensical rule. Hm, I would like to avoid adding an exception for O_PATH. While it is useful for lookup O_PATH is also often used simply as an opaque handle to a file. O_PATH is often used to simply identify or compare files, or for execveat(). Especially for cross-container interactions it would be nice to not generally allow O_PATH to be linkat()ed. The current behavior proposed in this patch should be enough.
