Live data from Hacker News

#include

blog.hboeck.de

131–132 of 132 posts

Re: #include </etc/shadow>

#131
post #22

Earlier quoted context omitted.

In a container or not, running a compiler-as-a-service as root is never the right way to run a compiler-as-a-service.

Why not? There's a good chance the user will be needing to install extra packages or libraries, or run custom makefile steps that require extra permissions the system designer couldn't anticipate. Running as root I think is the exact thing to run as. Then throw the whole VM or container away when handling a request for another user.

Running a compiler as root in general is not recommended. It's the principle of least privilege. Running without unnecessary privileges is a good idea for the same reason running in a sandbox is a good idea.

Re: #include </etc/shadow>

#132

Earlier quoted context omitted.

Um, yes it will? Linux namespeaces are linux namespaces; if you don't trust them we have bigger problems than Nix. It will certainly make sure the skids cannot do `#include ` and get useful information, for example.

That only works if you can turn your entire web application into a Nix build process, which is unrealistic at best. Nix is wonderful as a build tool, but it's quite a stretch to assume it's adequate for securing running applications. Plain containers, or even better, VMs are more suited for that purpose.

Your unsandboxed web application can perform a sandboxed nix build based on user input used in a very specific way. This contains the dangerous bit.
Post reply on HN