Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
rektide opened this issue Dec 27, 2019 · 3 comments
Closed

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

rektide opened this issue Dec 27, 2019 · 3 comments
Labels
feature request Issues that request new features to be added to Node.js. fs Issues and PRs related to the fs subsystem / file system. libuv Issues and PRs related to the libuv dependency or the uv binding. stale

Comments

@rektide
Copy link

rektide commented Dec 27, 2019

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.

@rektide rektide changed the title accept File Descriptors as a base path for fs open & readdir accept Directory File Descriptors as a base for fs open & readdir Dec 27, 2019
@bnoordhuis bnoordhuis added feature request Issues that request new features to be added to Node.js. fs Issues and PRs related to the fs subsystem / file system. libuv Issues and PRs related to the libuv dependency or the uv binding. labels Dec 27, 2019
@bnoordhuis
Copy link
Member

  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 available1, support for fchmodat(), fstatat(), linkat(), etc. is much spottier. You need those too if you want to avoid race conditions.

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

@github-actions
Copy link
Contributor

github-actions bot commented Mar 4, 2022

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 github-actions bot added the stale label Mar 4, 2022
@github-actions
Copy link
Contributor

github-actions bot commented Apr 4, 2022

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.

@github-actions github-actions bot closed this as completed Apr 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Issues that request new features to be added to Node.js. fs Issues and PRs related to the fs subsystem / file system. libuv Issues and PRs related to the libuv dependency or the uv binding. stale
Projects
None yet
Development

No branches or pull requests

2 participants