5 ms·
Immutability is an important step in the right direction. What I'd like to see come up is a distribution that in addition to immutability provides the followin
by EntrePrescott 4y ago
Immutability is an important step in the right direction.
What I'd like to see come up is a distribution that in addition to immutability provides the following:
1. separate install prefix directory for each currently installed package version (except for a minimal immutable core), thus allowing the coexistance of difference versions … and making access control policies practicable without the mess they are on a filesystem where there is a wild and hard to separate mix of stuff from lots of packages and other origins.
2. a modern and secure binding/mapping mechanism between the package install prefixes and what each of those and the user are supposed to see (dependig on profiles that can vary not only between packages but also e.g. between different users, different use cases etc). The "modern and secure" part meaning: not an old symlink based thing but something that uses the modern isolation techniques, cgroup/namespace, bind mounts, and the other mechanisms the kernel provides today.
3. a nice frontend for making the administration of those package-versions/mappings and the setting of access control policies based on them easy, with a sensible set of distribution curated profiles for the mappings, isolation settings and access control policies.
Parts of that already exist, e.g:
1. (the per-package version install prefix) has been spearheaded by Nix/NixOS … (but it's missing 2. and 3.)
2. the secure isolation, cgroups, namespaces, bind mounts etc part of 2. has been spearheaded by Containers… but their simple layering structure doesn't allow to map the more complex depndency graph of a package management system.
- waynesonfire 4y agoI really like these ideas. The OS, the interface that I would like to work with, that I have worked with my entire career, the interface that I'm an expert in, begins to recover some territory from the abomination represented by Kubernetes and Docker.
- DJBunnies 4y agoHey, some people prefer cattle to pets.
- 0x69420 4y agonixos missing 2/3 is what's behind my repeated insistence that nix is in sore need of a plan 9-esque host system. perhaps with fuchsia there's hope yet. cgroups and linux namespaces are great and all but pervasive namespace abstraction really really needs a fluid, low-friction interface for constructing those namespaces and subsequently examining precisely how they're put together. this is why typing ns in plan 9 is a huge eye-opener for a lot of newcomers. suid and friends ensure a perpetual lower bound on red tape and drudgery where traditional unix-likes implement namespaces.
- pmarreck 4y agoBeen a NixOS user for over a year now, quite happy with it, can you go over why 2 and 3 are "necessary"?
- 0x69420 4y agoin 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.
- johnny22 4y agoi wonder if you can take advantage of systemd-nspawn for most of that?
- tadfisher 4y agoJust 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.