undefined | Better HN

0 pointsGriffinsauce4y ago0 comments

Deno's permissions are per-process though, it's a big jump for sure, but also still leaves the door wide open for abuse by dependencies of any serious project.

0 comments

e12e4y ago

It does allow for some coarse grained improvements for certain services, though.

You might write an smtp daemon that only delivers email on to another service via LMTP - thus without ability to write to (or read from, depending on configuration) the file system, for example.

Yes, you can accomplish this via containers, too - but it's nice to get as much out of process isolation as possible, not to mention it is likelier easier to test and debug the closer to the surface of the runtime limitations are implemented.

tannhaeuser4y ago

How is that different from Node.js which also runs in a single process? Or does Deno create per-request processes (or v8 "isolates" etc) like CGI does?

zastrowm4y ago

I think the point was that it's not different from Node.js - and thus not much of a benefit.

If it was more along the lines of "I want to use this array helper library, but it shouldn't have any permissions" then it would be a lot more useful, but right now if your Deno app needs any file or network access, then all of your dependencies get access too.

GriffinsauceOP4y ago

Yes, this was my point. It's only trivially better in practice since you'll have to open all the doors nearly all the time.

We have so many dependencies that really only need to work in-memory and have zero IO needs. That part is not solved in Deno at all.

j / k navigate · click thread line to collapse