I am suggesting that if you pass:
deno --allow-read script.ts
# it's equivalent to
deno --allow-read=. script.ts
i.e. you can only read in the current directory only (.) unless further permissions are specifically given e.g. .,/etc/passwd (same for --allow-write).
While I agree cwd perm is useful at times, I worry equating allowing cwd to default is probably going to be really confusing. IMHO people are likely to use --allow-read if they want to run a small script they write all by themselves without any security concerns.
Maybe --allow-cwd as a short-hand for --allow-read=. --allow-write=.?
@hayd I am also concerned about the most convenient (deno --allow-read script.ts) to be also the least secure one. I would not mind if it had no default and the argument had to be added explicitly, but if there has to be a default then I think that --allow-read meaning --allow-read=. instead of --allow-read=/ is the lesser of two evils.
@kevinkassimo I think that --allow-read=/ is not that much more writing than --allow-read but at least it is explicit.
I think that would be in line of what @ry was pointing out in issue #3378.
I wrote about my concerns about having the / to be a default for --allow-run here:
and I think this is equally true for --allow-read and --allow-write.
In fact, I am also wondering if --allow-net shouldn't default to the script origin when running remote scripts to make sure that random scripts that people might run in the future don't DDoS other servers then their own, but this may not be as important as --allow-run and --allow-write because it can only access public services and here we are talking about user's data, possibly sensitive with ssh keys and other personal data.
I would not mind if it had no default and the argument had to be added
I am in favor of this approach. It always seemed dangerous to me to make the easiest thing to do ("I'll just do --allow-read to get the script to run") the most dangerous. It's extremely easy to write --allow-run=/ but it makes it abundantly clear that you're giving access to the whole thing.
I don't think the default should be the cwd (even though it's less dangerous than /) because that doesn't line up with common security models. On Linux and mac, you can run anything from any cwd so long as you have access to the files and directories you're pointing to. I don't think it's a good idea for Deno to introduce the idea of the cwd as the security sandbox when that paradigm exists nowhere else (that I've seen at least?).
Quick summary from what I've gathered:
--allow-read and --allow-write now (after 1.0) would be a major breaking change, and thus is quite unlikely to happen any time soon. The "no default" choice, as discussed above, would have been my preference, but it also would be breaking.--allow-cwd doesn't do anything to make the existing flags more secure, which seems to defeat the purpose. And I agree with @teleclimber — I don't think it's common for security tools to have a default based around the cwd.I think we should close this issue and just focus on informing and encouraging people to use the explicit --allow-read=<path> flag style, especially in documentation and READMEs.
Most helpful comment
@hayd I am also concerned about the most convenient (
deno --allow-read script.ts) to be also the least secure one. I would not mind if it had no default and the argument had to be added explicitly, but if there has to be a default then I think that--allow-readmeaning--allow-read=.instead of--allow-read=/is the lesser of two evils.@kevinkassimo I think that
--allow-read=/is not that much more writing than--allow-readbut at least it is explicit.I think that would be in line of what @ry was pointing out in issue #3378.
I wrote about my concerns about having the
/to be a default for--allow-runhere:and I think this is equally true for
--allow-readand--allow-write.In fact, I am also wondering if
--allow-netshouldn't default to the script origin when running remote scripts to make sure that random scripts that people might run in the future don't DDoS other servers then their own, but this may not be as important as--allow-runand--allow-writebecause it can only access public services and here we are talking about user's data, possibly sensitive with ssh keys and other personal data.