Bug 198570 - Add fnctl(F_GETPATH) support to FreeBSD
Summary: Add fnctl(F_GETPATH) support to FreeBSD
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords: feature
Depends on:
Blocks:
 
Reported: 2015-03-13 20:58 UTC by Niall Douglas
Modified: 2021-10-10 12:30 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Niall Douglas 2015-03-13 20:58:53 UTC
Related: #197695 (Fix broken KERN_PROC_FILEDESC sysctl), #197778 (Implement the AT_EMPTY_PATH race free Linux extension).

The lack of a facility to fetch the current path of an open file descriptor prevents race free filesystem code. For example, right now there is no reliable way of opening a fd to the containing directory of an open file handle, and therefore there is no way of unlinking, renaming or hard linking a file which has been relocated by a third party since it was opened.

Ideally FreeBSD ought to provide direct fd file operations (#197778), but even with a full suite of those there remains one occasion when you really must have the full path for an open fd: when you are symlinking from somewhere to wherever that fd references on the filing system.

What is annoying is that this is straightforward on Windows especially, and with a bit of work on Linux. On OS X F_GETPATH is unstable with respect to hard links, so it returns any of the hard links to a fd, and it's somewhat random which you get.

Would there be any appetite for FreeBSD to gain a F_GETPATH fnctl?

char buffer[4096];
int len;
if(-1==(len=fnctl(fd, F_GETPATH, buffer, sizeof(buffer))))
  errno might be EBADF, EOVERFLOW;
buffer[0...len] contains the zero terminated path of the hard link originally opened as the fd which is a null string if that hard link has been deleted.

This would bring to FreeBSD semantic equivalence to Linux and Windows. And not replicate the broken F_GETPATH in OS X.

Niall
Comment 1 Martin eto Misuth 2016-08-24 12:28:33 UTC
Although it probably doesn't make any difference, I would like to vote for this cause as well.
Comment 2 Shankar Giri 2017-06-04 04:49:05 UTC
FWIW +1 for me to vote for this as well.
Comment 3 Greg V 2021-10-10 12:30:04 UTC
Now we do have O_PATH with corresponding operations (bug 197778) but so far I've found a few reasons to "getpath" on these when working on xdg-document-portal:

- extattr_set_fd/extattr_delete_fd don't work with O_PATH, returning EBADFD (there's no space for an AT_EMPTY_PATH type flag in the API but maybe they should Just Work since these aren't *at calls, I'll try to patch this probably)
- linkat(AT_EMPTY_PATH) requires root privileges!? (was there no better, less restrictive way to deal with the security issues?)
- sometimes the program literally just needs to read the damn path to return to somewhere

Now, I wonder if KERN_PROC_FILEDESC is guaranteed to be reliable on O_PATH descriptors?

(Wait, do we even have the "broken filedesc" problem anymore? We do have fdescfs with the linrdlnk mount option, which basically provides the Linux style symlink API, and it's not "debugging only"!)