File access outside of bundle #22
Description
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.jsin 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?