Resolver tries to access absolute paths and crashes

[DASPRiD]

Describe the bug

When trying to access a path in a vite project which corresponds to an absolute path on your local disk, but is unreadable by the current users, vite crashes with an EACCESS error.

Ideally, Vite should not try to access absolute paths anywhere in the system. But at the least, it should catch EACCESS errors and know that it the tried path is invalid.

Reproduction

N/A

Steps to reproduce

1. Be on a Linux system and have a directory /recovery which is only readable by the root user
2. Create a basic vite project npm create vite@latest test and npm run dev it
3. Try to access http://localhost:<port>/recovery path

System Info

System:
    OS: Linux 6.2 Pop!_OS 22.04 LTS
    CPU: (32) x64 13th Gen Intel(R) Core(TM) i9-13900K
    Memory: 46.10 GB / 62.54 GB
    Container: Yes
    Shell: 5.1.16 - /bin/bash
  Binaries:
    Node: 18.15.0 - /usr/bin/node
    Yarn: 1.22.17 - /usr/bin/yarn
    npm: 9.5.0 - /usr/bin/npm
  Browsers:
    Chrome: 110.0.5481.96
    Firefox: 111.0

Used Package Manager

npm

Logs

12:00:54 AM [vite] Internal server error: EACCES: permission denied, realpath '/recovery/package.json'
      at realpathSync.native (node:fs:2644:3)
      at loadPackageData (file:///tmp/test/test/node_modules/vite/dist/node/chunks/dep-79892de8.js:22177:37)
      at tryResolveFile (file:///tmp/test/test/node_modules/vite/dist/node/chunks/dep-79892de8.js:22883:33)
      at tryFsResolve (file:///tmp/test/test/node_modules/vite/dist/node/chunks/dep-79892de8.js:22862:16)
      at Context.resolveId (file:///tmp/test/test/node_modules/vite/dist/node/chunks/dep-79892de8.js:22731:24)
      at Object.resolveId (file:///tmp/test/test/node_modules/vite/dist/node/chunks/dep-79892de8.js:43314:46)
      at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
      at async ModuleGraph.resolveUrl (file:///tmp/test/test/node_modules/vite/dist/node/chunks/dep-79892de8.js:61580:26)
      at async ModuleGraph.getModuleByUrl (file:///tmp/test/test/node_modules/vite/dist/node/chunks/dep-79892de8.js:61437:23)
      at async doTransform (file:///tmp/test/test/node_modules/vite/dist/node/chunks/dep-79892de8.js:41010:20)

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[bluwy]

Is your project inside /recovery? In which directory did you run npm create vite@latest? IIRC this is an intentional decision since constantly checking access permissions is perf-heavy, and most projects don't have that restriction.

[DASPRiD]

No, my project is in my home directory,

[DASPRiD]

When it comes to performance: You don't necessarily have to check for permissions, but you should catch exceptions when trying to access a guessed path.

[bluwy]

When it comes to performance: You don't necessarily have to check for permissions, but you should catch exceptions when trying to access a guessed path.

That's the issue. Catching errors is expensive, more so the effort to generate the error by node, which we will discard anyways. So we're making the assumption that you can access all your files inside your project directory to speed things up for most user's setups.

(To clarify, we only check for file existence, not file access permissions. The former is much cheaper to run)

No, my project is in my home directory,

I'd probably advise against this for similar reasons. Vite can handle it today, but you'll lose out on some fast-paths Vite has if you have your project in a deeper directory instead.

Overall, we technically can fix this issue, but it'll lose out performance for many users that won't have this specific setup, and I think it isn't worth it.

[DASPRiD]

Please elaborate on that.

The assumption that vite can access all files in the project directory is correct. The Problem is that vite searches outside the project directory (as I said, it tries to access /recovery on the root partition).

About your advise: If not in your home directory (where you have write access to), where would you put projects? Or did you misunderstood my description maybe? The project directory is in a deeper directory in my home folder.

[DASPRiD]

Just to clarify and be specific:

• The Vite project is in e.g. /home/dasprid/dev/test-project
• Vite tries to access /recovery/package.json on the hard drive (when trying to navigate to http://localhost:<port>/recovery on the dev server), which is only accessible by root

[bluwy]

I see, I thought you mean the Vite project being on the root / directly, which is common in Docker setups. If it's accessing at the root /recovery/package.json like you mentioned, then it's most likely coming from here.

Though I wonder how you're accessing that directory in the first place? Why do you access http://localhost:<port>/recovery manually.

But with that said, that specific error will be fixed by #12542 (comment) soon

[DASPRiD]

Though I wonder how you're accessing that directory in the first place? Why do you access http://localhost:<port>/recovery manually.

It's just a normal route in my React app, like any other path can be.

[DASPRiD]

By the way, I just verified that the breaking change was between v4.0.4 and v4.1.0.

[DASPRiD]

I think specifically this removal is responsible for this:
4a12b89#diff-9b81bb364c02eab9494a7d27a5effc400cacbffd3b8f349c192f890c37bfc83fL534-L535

[DASPRiD]

That being said, I tested against main and it seems to be resolved there.

FYI, a test which should always fail on POSIX systems, when not running in docker, would be to access /root on the dev server. I wonder if this could somehow be caught in a unit test. It's a little hard to do, since GitHub runners always run under root.

[bluwy]

Thanks for testing on main. Let's close this for now then, and if the issue re-appears we can look into it again.