Deno: Feature Request: Special Directory For Each App to Store Its Data Without Special Permissions

[ChayimFriedman2]

Apps usually maintain their settings, saved files, etc., but don't need full access to the global filesystem.

The Deno security sandbox is great; however, we can either approve full access forever (and take the risk of being hijacked), or re-approve each time, for example, the app want to save settings.

Instead, I suggest to insert a new API.

If an application want access to the global, wide filesystem (e.g. get access to the user's documents etc.) Then it needs special permissions. But there would be another permission, maybe even allowed by default, for accessing app-only data. This will be stored in a specific directory for each app (have to consider whether same file can access the folder across separate executions).

The model is similar to what already exist in permission-oriented frameworks, like Android apps or Windows 10 UWP apps.

And like those, maybe we want to allow access to separate, and allow less-global access to user pictures or documents folder even when the app is not allowed to access the whole system.

[Soremwar]

Whoa, this sounds like a great idea. A filesystem inside the sandbox could be great

Although I can see potential for malware by creating millions of files in your system, so there is gotta be a level of control over that

[kt3k]

@ChayimFriedman2
Deno's permission system has whitelist feature. See https://deno.land/std/manual.md#permissions-whitelist.

You can add these whitelist to the install command of your tool, and your tool only works with the limited access to the filesystem.

deno install --allow-read=$HOME/.your-tool --allow-write=$HOME/.your-tool your-tool-name https://path/to/script.ts

[ChayimFriedman2]

@kt3k But you have to include every time the folder the app save its data there. Instead I suggest common API when the app use relative path and Deno choose the actual folder.

[kt3k]

@ChayimFriedman2 If you install the command with deno install command, the permission flags will be written in the saved script.

Try the command like the below:

deno install --allow-net --allow-read --allow-write=$HOME file_server https://deno.land/std/http/file_server.ts

and check the file $HOME/.deno/bin/file_server.

[ry]

I'm open to adding localStorage https://github.com/denoland/deno/issues/1657

[kitsonk]

My thoughts are the same, plus IndexDB (#1699).

[nayeemrmn]

The winning suggestion in #1657 is having deno --origin <some origin> app.ts to specify the localStorage isolate. If we only allowed use of localStorage when an --origin is specified, I suppose it would act as the "special permission" requested here.

I wonder if we couldn't extend that to deno --location <some URL> app.ts... there are lots of web APIs that assume the existence of some document location (fetch(), location), and we kind of haphazardly treat the main module URL as such, but that wouldn't be good for storage and who knows what else. --location would save a lot of headache.

[teleclimber]

Please make it possible to disable access to localStorage and indexDB and anything else that has side-effects that gets added to Deno in the future. The reason is that things get a lot more complicated for those of us using Deno as the sandbox component of an application platform when apps can have side-effects that we can't control.

Example: I might use Deno to run code on demand on any of a large number of VMs. If an app stashed some data in locaStorage during one run, it's going to expect that to be there on a subsequent run. But that might happen on a totally different VM, so the data won't be there.

At least make it possible to export all localStorage/IndexDB for an origin from the command line, and provide an import function as well.

One more concern is that it creates the need for an additional layer of control around the amount of data that an app can store in their local storage. So long as deno only allowed access to the underlying OS file system, a host could could use the OS's facilities to track and control the user's storage usage. Once you start throwing localStorage data from every app into some internal db, the burden falls on deno to track, report, and limit storage usage.

Thanks