Deno: Capabilities of process

[zekth]

Just an idea with an issue i faced not adding --allow-read parameter in the deno command. It might be an extension of https://github.com/denoland/deno/issues/1225

I wanted to know if it's possible to get the capabilities of the running process, like using bit flags. For example:

process.capabilities; // return bit flag 00001010 (base 2) for example
process.IsAllowToRead(); // returns boolean

This can be usefull in some cases for mandatory permissions for code execution. Like when the service starts it tests its own permissions and throw: Process needs to have reading permission instead of the standard error Unable to read ...

At the moment it could be implemented like this. If (and i say IF because atm it's not really in the philosophy of deno) there is a .denoEnv file or something like this, we can add a field mandatory permissions to it checking the execution permissions before starting the process.

Your thoughts?

[hayd]

process.permissions = { allow_write: true, allow_env: false, ... }

[zekth]

So i assume there is something missing in the doc?
I was looking at: https://deno.land/typedoc/classes/_deno_.process.html

[hayd]

Sorry, I was just arguing that it should be the above. Not sure if it's already exposed.

Edit: perhaps it should be toplevel (Deno.permissions) not sure.

[zekth]

If not i think it would be very nice to expose it.

This may be related too: https://github.com/denoland/deno/issues/1008

But this is not accessible on ts side

[zekth]

import * as deno from "deno"

Here deno does not expose permissions or anything related.

[bartlomieju]

AFAICT what @zekth is proposing can't be done. Creating subprocess is done via Command which does not have any API to control such permissions.

ie. It's not possible to use Deno permissions in subprocess.

[zekth]

I may have misexplained but it was not about subprocess. It was about the main deno process. If i try for example : deno foo.ts --allow-read
In foo.ts, i wanted to know if i can check for example if i can read or not.

[afinch7]

I'm not sure how necessary this is since even if a permission is not enabled it will still give the user a prompt to allow it during execution.

[zekth]

Yes i found that but on the event of trying to access to this permission. In another case we can have for example a webserver which for sure requires --allow-net. So when you launch the process you have the prompt telling you this if you don't provide the permission. But admit there is an endpoint on the webserver which writes on the disk. You don't necessarily have the prompt accessible at this moment. For example on docker swarm deployement etc.
So you'll do a docker logs dockername but you can't send command to the prompt.

So you have the solution to use deno foo.ts -A but this is not really a solution.

[afinch7]

I guess what we really need is a flag that disables said prompts, and a soft failure mode for the code making the request.

[zekth]

Totally agree with this with revelant error like:

Read permission needed and not provided

[bartlomieju]

ref: #1591

[afinch7]

In an ideal world we could catch this before execution starts by directly importing the resources required(run function, read function, etc), and having the compiler error us if the permissions are not available. This would get pretty messy to implement though.

[zekth]

Closing this issue because --deny is somehow a solution of my use case. But like @afinch7 it would be nice to have at the start of execution.

[hayd]

I still think permissions = { allow_write: true, allow_env: false, ... } would be nice to have.

[afinch7]

While we are talking about the permissions I think that a allowing a permission shouldn't allow it for the rest of execution. To sum everything up so far we need:

• [x] No prompts command line flag for non interactive terminals
• [x] Allow once, allow always(same as the --allow-x flag), don't allow once, and don't allow don't ask again options for the prompt.
• [x] (Optional)A way to read current always allowed items from runtime. Looks like there is already a PR for this see #1875.

[zekth]

Closing because #1875 was merged