镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

feature request: impl whatwg/fs #42184

Description

@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

Activity

  1. moved this to Pending Triage in Node.js feature requestson Mar 2, 2022
  2. added
    fsIssues and PRs related to file-system APIs and the fs module.
    on Mar 2, 2022
  3. benjamingr commented on Mar 2, 2022

    @benjamingr
    Member

    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.

  4. mcollina commented on Mar 2, 2022

    @mcollina
    SponsorMember

    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?

  5. Metatron93 commented on Mar 2, 2022

    @Metatron93
  6. jimmywarting commented on Mar 2, 2022

    @jimmywarting
    Author

    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

  7. changed the title [-]impl whatwg/fs[/-] [+]feature request: impl whatwg/fs[/+] on Mar 2, 2022
  8. jimmywarting commented on Mar 2, 2022

    @jimmywarting
    Author

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

  9. mscdex commented on Mar 2, 2022

    @mscdex
    Contributor

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

  10. jasnell commented on Mar 2, 2022

    @jasnell
    Member

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

  11. jimmywarting commented on Apr 7, 2022

    @jimmywarting
    Author

    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

  12. github-actions commented on Oct 5, 2022

    @github-actions
    Contributor

    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.

  13. added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Oct 5, 2022
  14. added
    never-staleIssues and PRs exempt from automated stale handling.
    and removed
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Oct 5, 2022
  15. github-actions commented on Apr 4, 2023

    @github-actions
    Contributor

    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.

  16. added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Apr 4, 2023
  17. moved this from Pending Triage to Stale in Node.js feature requestson Apr 4, 2023
  18. github-actions commented on May 5, 2023

    @github-actions
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature requestIssues requesting new Node.js features.fsIssues and PRs related to file-system APIs and the fs module.never-staleIssues and PRs exempt from automated stale handling.staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions