denoland / deno

A modern runtime for JavaScript and TypeScript.
https://deno.com
MIT License
94.63k stars 5.25k forks source link

Permissions - enable glob patterns and relative paths for allow-lists (read/write) #11277

Open sramam opened 3 years ago

sramam commented 3 years ago

As I am getting comfortable writing modules and applications for Deno, it seems the permissions ability, despite being a big draw, is falling short of my anticipations.

For example, take klick - a snapshot library.

It needs permissions to read/write within a sub-directory. and that of a particular kind of file extension.

Ideally, I'd like to be able to use --allow-read=./**/*.snapshot --allow-write=./**/*.snapshot. Current implementation requires either absolute pathnames or --allow-write - which is essentially the whole system. Absolute paths names, besides being really ugly, are not portable across system. So degrade the developer experience. Glob-patterns that default to ${cwd}/* would be a very valuable constraint to add to the fs permissions.

Perhaps similar sensible defaults for other permissions can be determined - I just haven't used them enough to have a good insight yet.

sramam commented 3 years ago

@caspervonb, could I ask for the reasoning behind the 👎 ?

It seems that all "framework" tools that generate and manage code for their end-user (the snapshot library here, but more generally - angular, nextjs, create-react-app and their ilk) have similar requirements.

Neither the frameworks nor the user (in most cases) know filenames they will choose a priori.

Currently, the realistic permission choices are "exactly these" or the "whole system". And frameworks don't have a choice but to ask for the "whole system". At that point, Deno's promise of security is rendered to being a mere facade

As a user, I don't really want to give the framework read/write access to the whole system - cwd and under seems reasonable. Anything outside cwd, can be granted specifically (I imagine config files in home-dir etc).

It's definitely a better UX for the user both to understand the access-needs of a binary and to provide them.

Globbing by filetype is admittedly a narrower use-case, but as a user of a 3rd party library/binary, I'd like control over where and what on my system it can modify.

In general, I'd really like to have the possibility to have the narrowest possible permission-grants to any program that runs. And make is the least amount of specification load on the user.

caspervonb commented 3 years ago

could I ask for the reasoning behind the 👎 ?

Permissions shouldn't take blobs imo, too easy to mess up so I'm personally not in favour.

sramam commented 3 years ago

I see.
A bit ironically, the current implementation leads to widespread use of -A which renders any permissions moot. Even if -A was modified to apply to cwd by default, it'd be a huge improvement over current state of affairs.