feature request: impl whatwg/fs

[jimmywarting]

What is the problem this feature will solve?

it's sometimes scary to think that any npm module have access to the hole file system.
whatwg/fs is more secure by design.

Now that we have Blob's and whatwg streams then i think it would maybe be possible to implement something like the proposed whatwg/fs in NodeJS

Thanks to OPFS and theirs contributions to whatwg/fs and it's AccessHandle then it can performs async & sync operations and "write in place" more better than it's atomic counterpart operations that copies and replace the hole file once it's done writing.

What is the feature you are proposing to solve the problem?

this file/directory handles should be given to 3th party packages instead of any file paths...

the drag and drop web api have something like DataTransferItem.prototype.getAsFileSystemHandle
thinking we could maybe have a similar method on file descriptor or something that we can call xyz.getAsFileSystemHandle() from to get a whatwg/fs handle

having this would allow someone to write isomorphic application that works the same way on both browser and in NodeJS. a good usecase for it could eg be a zip:ing library or something or for webtorrent to work the same way in browser and also in nodejs applications

[benjamingr]

I have a bunch of questions on what this should accomplish - if the idea here is to provide restricted file system access based on whatwg/fs then we need a concrete proposal on how browser counterparts would look like?

cc @mcollina @jasnell

I think after we have a concrete proposal for this (and a general idea if this is a place we should experiment) we should involve the whatwg folks and get feedback.

[mcollina]

it's sometimes scary to think that any npm module have access to the hole file system.
whatwg/fs is more secure by design.

Can you clarify how this "security by design" would be brought to Node.js?

I think after we have a concrete proposal for this (and a general idea if this is a place we should experiment) we should involve the whatwg folks and get feedback.

What would be the browser-specific use calse?

[jimmywarting]

Can you clarify how this "security by design" would be brought to Node.js?

for instances, if you would hand a 3th party module a fileSystemDirectoryHandle then that module wouldn't be able to read the parent folders:

// this dose not work
fileSystemDirectoryHandle.getDirectoryHandle('../../../etc/hosts')
fileSystemDirectoryHandle.getDirectoryHandle('/etc/hosts')

you could also potentially only give it only read access if something like it where possible by some means: eg:

import { Torrent } from 'webtorrent'

const dirHandle = await xyz.getAsFileSystemHandle({ read: true, write: false })
new Torrent(dirHandle)

// webtorrent would also have the possibility to query permission using 
await fileSystemDirectoryHandle.queryPermission({ mode: 'write' })
await fileSystemDirectoryHandle.requestPermission() // how this would look in nodejs have have no idea...

browsers also have a sandboxed storage navigator.storage.getDirectory, don't know how it would fit into nodejs or if we somehow could give each module it's own sandboxed filesystem living in tmp directory or something. but with that sandboxed file system you got full read/write access to it.

What would be the browser-specific use calse?

Webtorrent would like to have access to a place on the disk to read/write data to, and it is working in both node and the browser

Deno also have a permission model built in with the cli
you can also pass arguments like --allow-read=~/downloads

[jimmywarting]

also this feature request would be blocked by #39015
and this feature request could also solve #37340

[mscdex]

Couldn't this be solved with the existing policy functionality?

[jasnell]

@jimmywarting:

it's sometimes scary to think that any npm module have access to the hole file system. whatwg/fs is more secure by design.

There are likely many good reasons to think about implementing the whatwg/fs API in core but sandboxing and restricted access to the file system are not among them. If we start talking about things in that way then folks will come away with entirely the wrong perception of the Node.js security model -- that is, there is no sandbox. Code running within Node.js would still be able to do anything the user has permissions to do. To restrict that will take more than just implementing this API, we would need to implement a proper permission and isolation system throughout which is a much larger and far more difficult problem.

[jimmywarting]

ok.. so there exist two spec to this...

1. is the whatwg/fs
2. the other is WICG/file-system-access

I first thought they where transfering/renaming file-system-access, but it was just splitet up into two separate things.

the whatwg/fs is the browsers own sandboxed file storage, it basically don't have any access to the harddrive, so it dose not have stuff like FileSystemDirectoryHandle.prototype.requestPermission to worry about it will have full control over their own sandboxed storage. it can also write stuff in-place or atomic. It can also have more fine grained control over flushing and seeking in the files.

the file-system-access is mostly just solo about getting access from the HDD and handing you a "Handle" to work with with a tiny bit more restriction on only allowing atomic writes and adding some requestPermission and queryPermission. file system access don't allow you to use the method createAccessHandle which the whatwg/fs is able to give you.

if we put the security stuff aside and giving out full access right and only focused on whatwg/fs then we don't need to worry about the permission and isolation stuff

[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 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.