On Thu, Aug 07, 2025 at 02:01:15PM -0700, Josh Triplett wrote: > I just discovered that opening a file with O_PATH gives an fd that works > with > > utimensat(fd, "", times, O_EMPTY_PATH) > > but does *not* work with what futimens calls, which is: > > utimensat(fd, NULL, times, 0) It's in line with what we do for fchownat() and fchmodat2() iirc. O_PATH as today is a broken concept imho. O_PATH file descriptors should've never have gained the ability to meaningfully alter state. I think it's broken that they can be used to change ownership or mode and similar. O_PATH file descriptors get file->f_op set to empty_fops when they're opened. So anything that uses file operations is off-limits (read, write, poll, mmap, sync etc.) but anything that uses inode_operations (e.g., acl, setattr) or super operations isn't per se. So that scheme isn't great. It shouldn't matter whether a write-like operation is implemented on the file or inode level. People do keep poking holes into O_PATH semantics at random. We're constantly fighting off such attempts because they would break the few useful promises that O_PATH file descriptors still give.
