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

File access outside of bundle #22

Open
Fishrock123 opened this issue Jun 16, 2016 · 1 comment
Open

File access outside of bundle #22

Fishrock123 opened this issue Jun 16, 2016 · 1 comment

Comments

@Fishrock123
Copy link
Member

Moving from the discussion in #15

This shouldn't work. The relative path just happens to work because I'm not protecting escaping from the bundle directory. Can you move the common folder to inside the parallel folder? Then use full paths to the file when using dofile. dofile("common/assert.js")

When we use the custom main feature, the bundle root becomes the directory holding the custom main.

...

I just don't want people getting the false idea that reading outside the bundle will continue to work when they zip their app.

Funny story. Today at work we had an incident with the luvit agent. There was a bug where a path had one too many dots ('..' vs '.') and was reading a file outside the bundle root. It passed all the tests since the tests ran in luvi mode, but when the agent was deployed, it crashed.

So my fear of differing behavior causing trouble wasn't unfounded after all.

I'm fine, however, with adding an explicit flag or something that allows overriding the root path. Or maybe we can have it look for a main.js in parent directories and automatically finding the app root.


I'm a little confused about this though. @creationix Is this just about dofile(), or about alls FS access?

I can imagine many applications that will need FS access outside of an app, but you seem to be indicating reading any file.

Consider an application which needs to store external config, what do we do about that? At very least, uv will need to be able to read outside of the bundle, and any likely module system will probably use the uv bindings which in turn will end up having the same effect.

Perhaps we could add a flag which treats a regular set of files as if it were a zip and limit access? Given how the majority of JS applications are written today I really don't think that it should need a flag to act how most users will expect when pointing to regular JS files.

Discuss?

@creationix
Copy link
Member

The fs actions in nucleus are intended only for loading assets bundled with the app (will be inside the binary once compiled and deployed). For normal fs access, you'll be using libuv or whatever bindings.

Keep in mind that these functions are also sync and should only be used during startup like sync require is done in node.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants