Investigate and improve permission prompting

[dsherret]

I think the permission prompting could be a little better and explanatory.

Edit: investigated all permission prompts...

1. Once deno supports Wasm modules then we can get rid of needing to save and read the cache directory.
2. Calling Deno.cwd() is necessary when the shell is created and cannot be lazily evaluated since it could change while the shell is executing, which would lead to very unexpected behaviour. This can be bypassed by providing an explicit cwd option.
3. Getting env access to all when the shell is initialized is necessary in order to get the environment state when the shell is spawned (can't be lazily evaluated, which is the same issue as the last point). This could be mitigated by supporting clearEnv() in the future.

[andrewbrey]

Related to both this issue and #27, I have taken to using a shebang on executable files which lets each file declare its own permissions:

#!/usr/bin/env -S deno run --allow-env=HOME,PATH --allow-net=deno.land --allow-read=.

I think this could be another useful thing to include in docs (it's already in the Deno docs, which is where I got it from, e.g. https://deno.land/manual@v1.29.0/examples/hashbang).

Going this route lets you invoke child scripts that can have different permissions from the calling Deno process:

script-a.ts

#!/usr/bin/env -S deno run --allow-env=PWD --allow-read=.

import { $ } from 'https://deno.land/x/dax/mod.ts'

const scriptB =  $.path.join(Deno.env.get('PWD'), 'script-b.ts') // file with executable bit set

await $`${scriptB}`

script-b.ts

#!/usr/bin/env -S deno run --allow-env=HOME --allow-run=/bin/ls

import { $ } from 'https://deno.land/x/dax/mod.ts'

await $`ls -lah ${Deno.env.get('HOME')}`

Could be worth a mention 👍

[sigmaSd]

You scripts seems to have wrong permissions ?

• dax will always ask for -allow-env=all
• even if you pass --allow-run=bin, dax will stat many paths to search for that bin, so you have to give --allow-read=1,2,3, all the paths that dax search

I wonder if can any of the above be improved ?

The other permissions are:

• downloading and writing the wasm file if it doesn't exist so --allow-net=deno.land and --allow-write=.local/share../wasm
• and after the first usage, it becomes just --allow-read=wasmfile

[andrewbrey]

You scripts seems to have wrong permissions ?

I was just quickly typing this as an illustrative example, not as a copy-pasteable script. You are right, more perms are typically needed for any script being run by dax but I figured pointing out the possibility of defining the perms in this way could be helpful as a documentation item which may help a subset of needs. 👍

[NfNitLoop]

Once deno supports Wasm modules then we can get rid of needing to save and read the cache directory.

I think you can do this before Deno supports native WASM modules. I haven't used WASM much myself, but as I understand it you just feed bytes into WebAddembly.Module() (example)

So if you transform your .wasm file to something like base64_encoded_wasm.ts (or .js or .json), you can just

import wasmBytes from "./base64_encoded.wasm.ts"

This lets deno install or deno compile cache the file for you. And lets deno run fetch (and cache!) the file for you without needing --allow-net or --allow-write access.

Shameless plug: If you don't want to base64-encode the wasm file yourself, you could use deno-embedder, which I wrote to do just this kind of thing.

[dsherret]

There is an option in wasmbuild (which dax uses to build the wasm file) to do that: https://github.com/denoland/wasmbuild#cli-flags (--sync). I believe it is slower to load, but I should measure to see how much slower as maybe it's not a big deal.

[dsherret]

@NfNitLoop deno-embedder looks nice!

[NfNitLoop]

As for cwd/HOME -- I'm not sure why dax needs to read those explicitly. For example, I can just run a Deno command without the --allow-env:

#!/usr/bin/env -S deno run --allow-run

const result = await new Deno.Command("env").output()
const outText = new TextDecoder().decode(result.stdout)
console.log(outText)

(Update): Aha, I see. Some of the built-in commands like pwd will need to know CWD to be able to operate correctly w/o calling a command. (At least, with the current implementation.)

---

Context: I'd avoided using Dax for a while because my very first experience with it was it asking for permissions to environment variables and reading/writing local directories, and network access, which seemed strange. (yes, even in the face of giving it --allow-run. Or maybe in especially for that reason.)

Months later, I was quickly making a script and forgot about my issues. This time I just threw on an -A because I was in a hurry, and I very much like the simplicity of Dax's interface. ❤️ And I am a fan of replacing Bash with Deno

I'd love to use Dax while granting it fewer permissions!

[NfNitLoop]

@dsherret I'm not sure if my PR link 2 days ago sent a notification to this issue, so just in case it didn't, see the above. 😊

I created a simple benchmark to test the "before" performance. Then I converted to use the --sync option, and found out that it's actually slightly faster. So if you were sticking to the other loading method for speed, there's no need AFAICT.

[dsherret]

Thanks, @NfNitLoop! That was a big improvement.

And I am a fan of replacing Bash with Deno

I agree. I'm actually probably doing a lightning talk on this subject next month at a conference.