Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Been a NixOS user for over a year now, quite happy with it, can you go over why 2 and 3 are "necessary"?


in the same way that flakes address build-time (and hence, nix project) boundaries, i want to easily control runtime boundaries

does a service need to see all of the store? no; just its closure. all of /proc? probably not. i would love to stop caring about secrets in the store

something as heavyweight as a container just to achieve those restrictions almost feels insulting, and something like pledge(2) approaches the problem from the wrong end.

then you take those well-defined boundaries, and you know exactly where you can deploy that service. take advantage of that well-known nix reproducibility, stub out the endpoints, plop it down on your local system, debug it at zero latency, revise it, deploy the fixed version.


Just about every restriction using cgroups/namespaces can be applied in systemd units. Many of the services in NixOS have been hardened through systemd, and there's an ongoing effort to harden all of them.


OS level "closures" are something I think about, and then the idea of composing said container/env closures into larger ones. I don't know if it's stupid or useful.


i wonder if you can take advantage of systemd-nspawn for most of that?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: