accept Directory File Descriptors as a base for fs open & readdir

[rektide]

Is your feature request related to a problem? Please describe.
At present opening files & looking at directories in Node.js requires passing in the full path. These operations would ideally also be able to accept directory file descriptors as options to them.

This helps alleviate a number of hairly race conditions. If directories are being moved around, the directory file descriptors will remain stable. Without this capability, it's not possible for a program to tell whether it's going to be writing to the same directory or not.

There are some performance advantages here too. Rather than having to walk up the file path, files can be opened directly from the starting directory file descriptor's location.

This is also useful for sandboxing & security. Applications can pass around directory file descriptors to each other or between modules, rather than having to reveal full paths to each other.

Finally, this capability would greatly ease interoperation with upcoming specifications such as WASI, which already use this file-descriptor based mode for all their operations. Both __wasi_fd_open and __wasi_fd_readdir require a starting directory file descriptor to work from. This is an integral part of their security model, part of the "capability" system of the api.

It's less explicit, but the design of the native file system specification for the web also works in a similar manner, where one never opens a full path, they only open things inside the tree of whatever handles (file or directory descriptors) that the page already has access to.

Describe the solution you'd like
I would like to see variants of or options to fs open/readdir that accept a starting directory fd, rather than requiring the full path to be passed in. In *nix land, this is done via openat() and using fdopendir() instead of open() and opendir().

This should give Node.js API capabilities that resemble how other js platforms are handling opening things, which should yield performance gains for users, freedom from an assortment of nasty race condition, & potentially some "capabilities" based security/sandboxing possibilities.

Describe alternatives you've considered
....

I believe changes to libuv would be required. As for platform support, there is a Stackoverflow discussing Windows parallels. Support most *nix'es is reported to be good.

/cc @cjihrig because he's been working on WASI a bunch & specifically in node.

[bnoordhuis]

1. I agree this would be useful to have.
2. This needs to be implemented in libuv first. I'd start by opening an issue there.

Problem: while openat() and fdopendir() are readily available¹, support for fchmodat(), fstatat(), linkat(), etc. is much spottier. You need those too if you want to avoid race conditions.

¹ Up to a point. Libuv supports macos 10.7, which doesn't have any *at() functions.

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[github-actions]

There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.

For more information on how the project manages feature requests, please consult the feature request management document.