Open kitsonk opened 2 years ago
In my opinion allow-all
should just be
{
"permissions": true,
}
* Having an explicit `allow` in the keys provides a mechanism to introduce `block` in the future (for example `"block-net": "deno.land"`) giving more granular permissions.
not a fan of this. it would mean you'd be able to do something with the config file that is impossible to do with just flags.
Also I don't think it makes sense to support comma separated items in a string, only arrays should be usable (for the perms that take multiple values)
I'm in favor of the proposal in general (especially combined with tasks/scripts), but I'm not in favor of top-level permissions
key. IMO there's not much benefit of having a single top-level definition if most projects contain several entrypoint, each of them requiring different permissions. With this proposal it becomes non-obvious how permissions would be applied to different entry-points.
As for the signature of permissions
object I believe we should follow definition used in TestDefinition
and WorkerOptions
as closely as possible:
IMO there's not much benefit of having a single top-level definition if most projects contain several entrypoint, each of them requiring different permissions.
But there are currently no semantics in the config file for entry points, so it becomes a chicken and egg.
And specifically the example of the "test" permissions seems to apply a top level "permissions"
key that would be the default set of permissions to be applied. Given the current lack of a way to express entry points in the config file, it only seems logical to describe the default set of permissions, and then allow addition/different sets of permissions to be described on individual entry points when they become available.
My key point was that we shouldn't flatten permissions to be different top level keys.
not a fan of this. it would mean you'd be able to do something with the config file that is impossible to do with just flags.
That is already the case with TypeScript compiler options.
As for the signature of
permissions
object I believe we should follow definition used inTestDefinition
andWorkerOptions
as closely as possible:
I am agreeable with that, and it makes sense in the context of "top level" permissions and allowing overriding for different tasks/entry points.
IMO there's not much benefit of having a single top-level definition if most projects contain several entrypoint, each of them requiring different permissions.
But there are currently no semantics in the config file for entry points, so it becomes a chicken and egg.
And specifically the example of the "test" permissions seems to apply a top level
"permissions"
key that would be the default set of permissions to be applied. Given the current lack of a way to express entry points in the config file, it only seems logical to describe the default set of permissions, and then allow addition/different sets of permissions to be described on individual entry points when they become available.My key point was that we shouldn't flatten permissions to be different top level keys.
Okay, this is a valid point. You're also right about chicken and egg problem. I guess this is a good way to start iterating on these features. Let's do it 👍
not a fan of this. it would mean you'd be able to do something with the config file that is impossible to do with just flags.
That is already the case with TypeScript compiler options.
yes, but those are "external", as in, they arent something made by/for deno exclusively. the only other option for thsoe would implement all options as flags, which would be unrealistic. Also this would mean we have some permission related features as flags, but other features only in config file, making things just more confusing imo by having things "all over the place" (i am aware it isnt as bad as i just made it sound, but my point stands).
I'm in favor of the proposal in general (especially combined with tasks/scripts), but I'm not in favor of top-level permissions key. IMO there's not much benefit of having a single top-level definition if most projects contain several entrypoint, each of them requiring different permissions. With this proposal it becomes non-obvious how permissions would be applied to different entry-points.
This could be tackled by allowing composition of config file, an extends
of sorts
{ "permissions": { "allow-all": true, "allow-env": true, "allow-hrtime": false, "allow-read": [ ".", "/tmp" ], "allow-write": ".", "allow-net": "deno.land,nest.land" } }
Thought about the blocklist thing again: how about instead
{
"permissions": {
"env": {
"block": ["PATH"],
"allow": ["HOME"]
},
"hrtime": false,
"read": [".", "/tmp"],
"write": ["."],
"net": ["deno.land", "nest.land"],
"prompt": true
}
}
so to specify the blocklist, its an object instead of a proper value for the perm directly. this would all us to add blocklist support at some later point as it would be an extension from what it would be without. also this would allow for allowing specifying --prompt
behaviour on a permission level instead of just a global level
I really like this proposal. It encourages fine-grained control over what directories can be read and written to, for example. At the moment, it's inconvenient to get this precise with command line options.
I really like this proposal. It encourages fine-grained control over what directories can be read and written to, for example. At the moment, it's inconvenient to get this precise with command line options.
@crowlKats When you said
the only other option for thsoe would implement all options as flags, which would be unrealistic
by "unrealistic" did you mean "inconvenient"? My impression is that most software which executes with more than a few flags either builds them using a script or hardcodes them into a script.
Adding additional CLI flags from options actually sounds useful (as no extra filesystem i/o in the form of reading/writing a config would need to happen in dynamic execution).
EDIT:
I was initially in favor of this proposal as-is, but now after thinking it over the only thing I desire is a flag to opt-out of the functionality to load permissions from the config. I just think about a scenario of updating to a new version of some popular third-party module that's been hacked and having said module write to deno.json
to provide new permissions for itself that could be utilized the next time the script is ran.
For the strictest security, I would want to be able to explicitly opt-out of reading permissions from the config and instead require all the permissions be provided via flags... that's what I would always want to run in production.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.
For the strictest security, I would want to be able to explicitly opt-out of reading permissions from the config and instead require all the permissions be provided via flags... that's what I would always want to run in production
Related: https://github.com/denoland/deno/issues/13452 will become even more important if this feature is implemented
Now that we have permissions scoped to tests, it would probably be best to just unify a deno.jsonc
config property permissions
with Deno.test
's permission object type. Also, when it is string | URL
we can just only accept string
. I think it would be a bad idea to have two different type of objects for specifying permissions and this would give us a chance to have a uniform behavior.
Edit: I hid this because I did not realize that this was already mentioned above.
I'm in favor too. Added to 1.22 milestone.
I'm working on this in https://github.com/denoland/deno/issues/12763.
For the first pass I think we should cut the scope a little bit, namely by not supporting permissions in remote configuration file. Instead we should print a warning, pointing to an issue about it. The reason is that it will cause a bifurcation in behavior depending if the config file is local or remote, in the former case we'll be resolving allowlists relative to config file, while in the latter we'd have to fallback to CWD. I think this is gonna be a surprising behavior.
I'm working on this in #12763.
@bartlomieju You linked to this issue 🪞. Did you mean #14520?
Yes
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.
:eyes:
there is a short way to achieve this, run this in window terminal:
alias d="deno run --allow-net --allow-env --allow-read --unstable" $*
and you then d foo.ts
On #14520, @bartlomieju said:
There's no consensus about this feature in the core team. Closing for now.
Is now maybe an ok time to retry corralling consensus?
I would like to be able to set default permissions for each command individually. Example:
{
// Global permissions
permissions: {
'allow-read': ['./config.json']
},
// Additional permissions for any `deno test` command
test: {
permissions: {
'allow-read': ['.'],
'allow-write': ['tests/fixtures'],
'allow-env':true,
}
}
}
Isn't this kind of functionality practically already in place, provided by the task runner (deno task
) and configurable through task definitions? IIRC, the task runner was not yet implemented at the time this issue was created.
Isn't this kind of functionality practically already in place, provided by the task runner (
deno task
) and configurable through task definitions? IIRC, the task runner was not yet implemented at the time this issue was created.
Yes, you can specify the permissions via tasks definition. The core team's hesitation is coming from the fact that if you specify permissions in the config file, adding the "write" permission allows to then update the config file by rogue dependency that would be able to escalate permissions further. We're currently focusing our efforts on other parts of the runtime, but we might revisit this issue in Q1 2023.
Isn't that just as much of a concern right now with the task runner? Task aliases are also vulnerable to being edited by a rogue dependency.
Here is another proposal https://github.com/denoland/deno/issues/17177
It has in my opinion some advantages:
Maybe the maintainers can define a starting point for the threat model? I feel we're going back-and-forth in a piecemeal fashion. I'd love to have full lay of the land to be able to propose something that's able to be well received.
My 2 cents:
Deno requests write access to the config file "deno.json"
. It would be independent of the --allow-write
flag and be configured with --allow-write-config
flag or no flag at all and only using the prompt.cp
, mkdir
, etc. Maybe using an $
or somethink like that. For example: --allow-write=$HOME
for the user's home directory.My main problem with json config is that you cant express very useful permissions, like --allow-read=cache-dir() or even --allow-cache-dir=cache-dir().join(myapp) in a cross platform way
In my opinion these happens all the time, and neither the current system or this proposal improve on thar, which is why ppl just give up and use --allow-read=all
My main problem with json config is that you cant express very useful permissions, like --allow-read=cache-dir() or even --allow-cache-dir=cache-dir().join(myapp) in a cross platform way
@sigmaSd I'm not sure that I understand this exactly, but it seems like a suggestion of some kind of dynamic value resolution. The ability to audit fully-resolved, static values prior to runtime is foundational to the security of permission configuration.
That's a valid point
It's a dynamic system, it can be improved by putting the permission file in a immutable registery like deno.land but it still is dynamic
Isn't that just as much of a concern right now with the task runner? Task aliases are also vulnerable to being edited by a rogue dependency.
@lilnasy it's not as much of a concern because it doesn't apply to every deno run/test/etc
invocation and with deno task
you probably have some idea about what task in what config file you are running. With deno run
if you don't have a config file and the script has write permissions, then the malicious script could write one in an ancestor directory which would then be auto-discovered on the next run. With the config file being modified for deno task
, it is still something that people should be aware about (along with scripts that modify code that someone will probably execute with elevated permissions), but again, not as much of a concern.
How about another flag to use the permissions from the config file? Something like --allow-from-config
or --permissions-from-config
🤔 Then you would have to explicitly specify that you want to use the permissions from the config.
Admittedly that doesn't fix the problem all together, but imo brings it down the a similar threat level we currently have with deno task
@DerZade yeah, that’s been discussed internally for certain commands like deno test
and bench
. Basically if you run without the flag it would prompt and show you the permissions to confirm, or you could provide a flag to use the permissions from the config file and override the prompt. This would help prevent people from accidentally running their tests without permissions granted and have it fail halfway through.
For deno run
, I’m not sure how useful it is to have permissions in the config file because someone could define a deno task
. Anyway, this is just all my personal opinion.
I agree that deno task
helped with this a lot. My personal setup usually includes three tasks, which all execute deno run
. One with just the permissions, another one with the permissions and --watch
and a third one with the permissions and --inspect-brk
.
Now I have basically the same task with just minor differences and each of them includes the same (very long) permissions options.
So every time I need change permissions, I have to do it three times. That is still bothering me a bit 😅 and why I personally would welcome defining the permissions in the Deno config (or even a external config).
Maybe the permissions in the config file could be assigned only to tasks (instead of globally) because there can be different modules that you want to run with different permissions.
I remember an idea I suggested some time ago to include descriptions in the tasks (https://github.com/denoland/deno/issues/14949). Although it was rejected, it had the ability to configure a task using an object with different properties, not only a plain string. This would allow to configure the permissions in a more ergonomic way:
{
"tasks": {
"serve": {
"run": "deno run ./server.ts",
"allow": {
"net": "localhost:3000",
"read": ["./img", "./styles"],
},
},
}
}
It would be equivalent to:
{
"tasks": {
"serve": "deno run --allow-net=localhost:3000 --allow-read=./img,./styles ./server.ts"
}
}
Shebang is aleeady a nice place for permissions, it just doesn't work on Windows: https://github.com/denoland/deno_task_shell/issues/23.
I think I'm running into this problem. I want deno test
to come with some permissions. But as far as I can tell, I have to either:
deno test
and instead define a custom task and remember to use deno task test
.I want
deno test
to come with some permissions. But as far as I can tell, I have to either:
- Specify the permissions on the command line every time; or
- Give up on using
deno test
and instead define a custom task and remember to usedeno task test
.
Deno can't know which permissions you want to grant to executable code (whether it's code that's executed by deno run
, deno test
, etc.) without your specifying them… somewhere.
This is my view of the current state of things: if you plan to locally execute code (more than once using the same options) by interactively typing a command into your terminal, and you don't want to type very much each time to execute that code (who does? 😅), then specifying a task using the task runner is the simplest way to granularly open up the security sandbox — then, like you said, it's as simple as deno task test
to run your tests — or deno task start
to start your program — with only the minimally necessary permissions defined in those tasks.
However, if you want to grant all permissions (disable the security sandbox) for all test modules whose filenames pattern match by default when running deno test
(and all of those modules' dependencies)… then you can always use deno test -A
.
Yes, perhaps I was not clear. I want to specify in my config file what permissions deno test
should run in, so that people coming to my project can use the standard deno test
command. Right now I have to instead include special instructions in my readme for a nonstandard testing command.
I want to specify in my config file what permissions
deno test
should run in, so that people coming to my project can use the standarddeno test
command.
This would violate the security concept of sandbox-by-default and explicit granting of permissions: it would be implicit granting of permissions (because configuration files are implicitly resolved).
Right now I have to instead include special instructions in my readme for a nonstandard testing command.
Can you instruct users to type deno task test
instead of deno test
?
Can you instruct users to type
deno task test
instead ofdeno test
?
Yes, I can. And then this makes Deno an inferior ecosystem to npm, where to learn how to run a project's tests, I don't need to look it up in the project's readme. I just always use npm test
.
As deno run
interactively asks for the most granular permissions the code requires, and the user answers, it would be really handy to have an option to save these permissions somehow, in a configuration file, as a tasks
entry, or even as a CLI command.
following @oscarotero idea, here is a real app example of why having it declare as an object improves the readability of allowing permissions in the deno config
Please consider my proposal #26372 as well. This proposal seems fine, but in my issue I suggest a simpler solution, but one that also supports multiple "profiles" that can be applied appropriately in different contexts. If my proposal is less appealing, I'd suggest adding the idea of multiple "profiles" to this proposal, so that you aren't globally applying the same set of permissions to all contexts. For example, my proposal would allow you to use one profile for deno run
and a different profile for deno serve
.
Context
Currently Deno supports a
deno.jsonc
configuration file which allow users to provide a configuration file that can provide TypeScript compiler options, lint options and format options.It does not currently support other information that can only be expressed on the command line, while this proposal is what
Semantics
"permissions"
section is parsed and the permissions are applied from the"permissions"
section. Any other flags on the command line are ignored."permissions"
a warning should be issued to stderr that permissions from the config file are being applied.true
orfalse
. If the key supports a value, these can be either a string delimited the same way on the command line, or an array of strings.--allow-read
and--allow-write
) the config file is used as a base, versus the cwd.Examples
An example of a configuration file using permissions:
Considerations / Open Questions
"permissions"
makes it easier to understand explicitly that these effect the runtime permissions. It also allows the definition of the semantics of"permissions"
to evolve independently of the rest of the configuration file, as well as opens an easy opportunity to be able to set permissions on other things in the future, like tasks/scripts independent of the top level permissions.allow
in the keys provides a mechanism to introduceblock
in the future (for example"block-net": "deno.land"
) giving more granular permissions.--no-prompt
/--quit
is supplied on the configuration is set, should the process just terminate or just allow the program to run with the supplied permissions?--allow-read
--allow-write
is not possible. Does this mean that relative paths just error, or that it defaults to the cwd in those situations?cc/ @bartlomieju @ry