-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
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
fix: prevent serving unrestricted files (fix #2820) #2850
Conversation
fsServeRoot
to prevent serving unrestricted files (f…
fsServeRoot
to prevent serving unrestricted files (f…Co-authored-by: Shinigami <chrissi92@hotmail.de>
Thanks for pushing for this change @antfu. Some initial thoughts. @marvinhagemeister said they are planning to support an array of folders, instead of only one fsServeRoot. #2820 (comment). I don't know exactly what would be the use case for this? Maybe in a monorepo, you only would like to allow for a few internal packages and not all of them? I think that it would be good to have an option to support common monorepos, maybe behind an option. But this to me should be pushed to another PR, as it is not related to the security issue at hand. |
About support for an array of serve roots, that could be added later if needed and we can merge this PR without it. We could think if |
Co-authored-by: patak <matias.capeletto@gmail.com>
@antfu tests are failing because of missing imports from utils |
Added |
Converting to draft for now as we need to have some rework on this to provide better DX for users to migrate this change. |
Tested locally on Windows and is working as expected 👍🏼 |
Co-authored-by: patak <matias.capeletto@gmail.com>
Co-authored-by: Shinigami <chrissi92@hotmail.de>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thoughts (non-blocking): Okay, so if understand everything correct, we are currently provide a new option to set the root and no upper files are allowed to be accessed.
In Mono-Repos we have some strategies to find the root automatically, but for non-Mono-Repos we don't have such.
But the fsServeRoot
is optional and therefore this fix doesn't apply at all for non-Mono-Repos, does it?
If so, I would highly suggest to search for just e.g. package.json
or .git
and let the user/developer define its own fsServeRoot
to override it and give the responsibility to them (the user).
So we are strict, but it's possible to relax the strictness.
What are your thoughts about this?
@Shinigami92 Sorry wdym? For non-monorepos, it's limited to the project root. |
Ah, so this is this: Okay 🙂 |
* Accepts absolute path or a path relative to project root. | ||
* Will try to search up for workspace root by default. | ||
*/ | ||
root?: string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussion with @patak-js, we are likely to add more options to configure /@fs/
to enhance further security in the future. For example, disabling dotfiles (.env
) by default (e.g. sirv). Changed this to an object for further extensions.
…ng Vite (> 2.2.4) Although it shouldn't cause problems for most Vite Ruby projects, after vitejs/vite#2850 files outside the Vite root would not be served by the dev server middleware. By explicitly setting `server.fsServe.root`, we ensure that every file in the project can be served raw if needed.
Co-authored-by: Shinigami <chrissi92@hotmail.de> Co-authored-by: patak <matias.capeletto@gmail.com>
@@ -4,7 +4,7 @@ import { join } from 'path' | |||
|
|||
// https://github.com/vitejs/vite/issues/2820#issuecomment-812495079 | |||
const ROOT_FILES = [ | |||
'.git', | |||
// '.git', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the explanation for this?
Description
fix #2820
serve.fsServeRoot
to prevent serving entire fsAdditional context
What is the purpose of this pull request?
Before submitting the PR, please make sure you do the following
fixes #123
).