Skip to content
This repository has been archived by the owner on Jan 8, 2020. It is now read-only.

Option to disable filesystem restrictions #480

Open
waxlamp opened this issue Jan 30, 2015 · 8 comments
Open

Option to disable filesystem restrictions #480

waxlamp opened this issue Jan 30, 2015 · 8 comments

Comments

@waxlamp
Copy link
Member

waxlamp commented Jan 30, 2015

The standard tools take pains to stop access to file paths outside of the web root directory. With the notion of Tangelo as an application driver that can basically do whatever it wants (i.e., the same freedom a regular desktop application would have), it may be the case that accessing files not explicitly in the web root might be useful.

If we implement this option, I would want to include documentation explaining that using the option makes it harder to pack up and transport a given application. For the notion of a self-sufficient Tangelo application, in other words, you wouldn't really want to use this option. But that notwithstanding, maybe it would be useful during development, or maybe there are legitimate reasons to use it in production.

@jeffbaumes
Copy link
Member

I agree that this could be useful - but the existing restriction is useful also. Does the current restriction disallow things like symbolic links to external paths?

@waxlamp
Copy link
Member Author

waxlamp commented Feb 2, 2015

As far as I know, symlinks like that would not be disallowed. I will do a test to make sure.

Do you think we should tighten the restriction to apply to symlinks as well? It starts to feel like encroachment into OS duties at that point, but maybe not.

In any case, it seems like this would be a useful option to add. Since it would be chosen by the application developer (e.g., placed into a launcher script) it seems like the freedom to choose which style of useful would be there. I will go ahead and remove the dubious tag.

@waxlamp waxlamp removed the dubious label Feb 2, 2015
@jeffbaumes
Copy link
Member

No, I don't suggest adding more logic for that if it is not there already - I was just wondering if it truly enforced encapsulated Tangelo apps, which it seems it does not in its current form, though it certainly would catch mistakes like this in most situations.

@waxlamp
Copy link
Member Author

waxlamp commented Feb 2, 2015

Ok good, I agree with not adding that logic. And on second thought, I think that symlinks to external files should be allowed. That is, after all, a file in the current directory as far as any particular software looking at the directory knows. The filesystem restrictions apply to situations where someone uses a sequence of ../ file path components to sneak their way out of the webroot, or just plain names an "illegal" file with an absolute path. So, symlinks linking out are sort of a different thing anyway, that already conforms to the rules about staying inside the webroot.

@waxlamp
Copy link
Member Author

waxlamp commented Feb 2, 2015

Also, I just remembered why I opened this issue - in my NYC taxi data repository, I have things set up so that the (very large) database file is generated in one directory, while the Tangelo application for querying it lives in another. Right now I have a symlink in the Tangelo app directory that points to the database file, but the other way to do this would be to invoke Tangelo with the loose filesystem option activated. I think that would be a legitimate use case.

@jeffbaumes
Copy link
Member

Agreed that is a legitimate use case.

@waxlamp
Copy link
Member Author

waxlamp commented Feb 2, 2015

Ok cool. I may go ahead and add this feature then, and use it in the NYC repo. After some of these applications stabilize, it may be time to cut another Tangelo release, so these features go out to PyPI.

@jeffbaumes
Copy link
Member

Sounds like a plan.

@waxlamp waxlamp changed the title Option to disable filesystem restrictions? Option to disable filesystem restrictions Feb 2, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants