You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently a user trying to safely run a script that does basic input/output might type something like this at the command line:
deno run --allow-read=/home/user/pics --allow-write=/home/user/thumbnails thumbnailer.ts --source=/home/user/pics --dest=/home/user/thumbnails
It's annoying to have to write directories twice: once to get a permission, and again to pass it on to the script.
Since there is a proposal for a permissions metadata file (#3675) I suggest that it (or whatever permission acquisition mechanism system gets implemented) includes a way of eliminating this duplication of work.
The permissions file (or whatever it is) could include something like this:
deno run thumbnailer.ts --source=/home/user/pics --dest=/home/user/thumbnails
Deno would parse the command using the same std lib parse function (https://deno.land/std@0.77.0/flags) and match the passed arguments to the metadata and set permissions where it finds matches.
It's possible the metadata should allow the developer to specify an object identical to the parse function's options object so that both deno and the script parse the arguments in the same way.
If there are arguments that don't have an option, the metadata file could follow parsedArgs format as well:
deno run uploader.ts my/files/to/upload/ https://backupservice.com/upload/
I realize the more correct way of solving this is to use capability based security (#378), but that's more of a paradigm shift, while what I describe above could be added to a metadata file (or whatever) without any breaking changes.
The text was updated successfully, but these errors were encountered:
I think the issue of duplication in a command line is best solved with variables, e.g.
source=/home/user/pics
dest=/home/user/thumbnails
deno run --allow-read=$source --allow-write=$dest thumbnailer.ts --source=$source --dest=$dest
or
setsource=/home/user/pics
setdest=/home/user/thumbnails
deno run --allow-read=%source% --allow-write=%dest% thumbnailer.ts --source=%source% --dest=%dest%
This seems easier to use (don't need to create a separate permissions file), easier to inspect (no need to look into a separate file to understand what's supposed to happen), and easier to implement (in fact, it's already done - most operating systems have some sort of shell).
Currently a user trying to safely run a script that does basic input/output might type something like this at the command line:
It's annoying to have to write directories twice: once to get a permission, and again to pass it on to the script.
Since there is a proposal for a permissions metadata file (#3675) I suggest that it (or whatever permission acquisition mechanism system gets implemented) includes a way of eliminating this duplication of work.
The permissions file (or whatever it is) could include something like this:
With this metadata the command would look like:
Deno would parse the command using the same std lib parse function (https://deno.land/std@0.77.0/flags) and match the passed arguments to the metadata and set permissions where it finds matches.
It's possible the metadata should allow the developer to specify an object identical to the
parse
function'soptions
object so that both deno and the script parse the arguments in the same way.If there are arguments that don't have an option, the metadata file could follow
parsedArgs
format as well:... which would be used like in this command:
I realize the more correct way of solving this is to use capability based security (#378), but that's more of a paradigm shift, while what I describe above could be added to a metadata file (or whatever) without any breaking changes.
The text was updated successfully, but these errors were encountered: