Hacker News Reader

Comment by yjftsjthsd-h | Hacker News Reader

without the overhead of completely containerizing them up front.

What overhead? `docker run --rm -it -v $PWD/untrustedprogram:/untrustedprogram:ro ubuntu:latest`, done. Use x11docker if needed.

View on HN

> `docker run --rm -it -v $PWD/untrustedprogram:/untrustedprogram:ro ubuntu:latest`

Not sure if running a program as root in a container is the best approach to "fully sandbox" - depends on what the goal is, obviously.

This isn't upvoted enough. I use that trick verbatim to just wrap a container's execution environment around my $PWD. It's useful way beyond just isolating a program.

I've used `alias shit='docker run --rm -it --entrypoint /bin/sh -v $PWD:/workdir -w /workdir'` for a long time. This way, whenever I need, I can just run `shit alpine` or `shit ubuntu` or whatever.

I have the same as dri (docker run interactive) and dri_cwd so current directory only mounts intentionally (with dri_cwd)

The overhead of keeping a separate copy of the OS, presumably.

Wouldn’t you need something like gvisor and or running under a different user or podman to make this really safe? If you don’t trust the binary they can still just break out the container.

Container escape isn't supposed to be that easy these days, but yes there is a tradeoff between security and convenience and performance. I was objecting to the claim of overhead in using a container; if you need more protection than you can get on the same kernel then you'll pay for it in virtualization costs (granted, that's not super high anymore either).

That's a lot of overhead if you don't already have docker installed, don't have the the ubuntu image installed, etc.

So Docker is a zero cost solution now?

Reply on news.ycombinator.com