3 ms·

>Again that's accidents of Unix history rather than sensible security design. In a single-purpose container running as root is fine In an ideal world, a user w

by zaarn 9y ago

>Again that's accidents of Unix history rather than sensible security design. In a single-purpose container running as root is fine In an ideal world, a user would be a container with shared filesystem. There are lots of uses for a shared filesystem (primarly backup tools). A lot of container tools make it very hard to properly backup and restore containers. >Interesting, I've found exactly the opposite (though I mostly work with maven which has always been good at reproducibility, maybe npm is less good). Reproducable here means: I can pull up the same exact server environment, including all versions. Build systems only do that for the language itself but system dependencies (OpenSSL, curl, etc.) might have different versions and don't help much in fixing that if it causes a bug to appear or disappear. >those three instances of AppSomething are now able to interfere with each other a bit, but they're not quite as similar as you'd expect either. Do you really need that much complex granularity in your isolation model? Interference does not happen if you properly isolate the users which is certainly possible on a modern system. Systemd makes it extremely easy to essentially mount everything but the immediate app data as read-only. No interference. And yes, I need such complex granularity.

lmm 9y ago
> In an ideal world, a user would be a container with shared filesystem. There are lots of uses for a shared filesystem (primarly backup tools). I see the shared filesystem as much more of a liability than an asset. It's too easy to have hidden dependencies between seemingly unrelated processes that communicate via the filesystem; when a file that should be there isn't, there's no way to ask why. > Build systems only do that for the language itself but system dependencies (OpenSSL, curl, etc.) might have different versions and don't help much in fixing that if it causes a bug to appear or disappear. Having a single dependency manager that can bring up consistent versions of all relevant dependencies is important, agreed, but I think the language dependency managers are closer to having the needed featureset than operating system package managers are. Operating systems are far too slow to update library dependencies and have far too little support for making local or per-user installs of a bunch of packages - of course the ideal system would support both, but I can live without global installs more easily than I can live without local installs. I'm lucky already in that the JVM culture is more isolated from the rest of the system - often the only "native" dependency is the JVM itself, and so using the same versions of all jars (and possibly the JVM) will almost always reproduce an issue. My inclination would be to move further in that direction, integrating support for containers or unikernels into the language build tools so that those tools can build executable images that are completely isolated from the host system. > Interference does not happen if you properly isolate the users which is certainly possible on a modern system. > Systemd makes it extremely easy to essentially mount everything but the immediate app data as read-only. No interference. Sure it's possible, but again it's not the natural path, it's not the way the OS or a lot of the traditional-unix tools you get expect it to be. Things like CPU quotas for users feel very bolted-on. > And yes, I need such complex granularity. Why? What does all that extra complexity gain you?

by zaarn 9y ago

lmm 9y ago

> In an ideal world, a user would be a container with shared filesystem. There are lots of uses for a shared filesystem (primarly backup tools). I see the shared filesystem as much more of a liability than an asset. It's too easy to have hidden dependencies between seemingly unrelated processes that communicate via the filesystem; when a file that should be there isn't, there's no way to ask why. > Build systems only do that for the language itself but system dependencies (OpenSSL, curl, etc.) might have different versions and don't help much in fixing that if it causes a bug to appear or disappear. Having a single dependency manager that can bring up consistent versions of all relevant dependencies is important, agreed, but I think the language dependency managers are closer to having the needed featureset than operating system package managers are. Operating systems are far too slow to update library dependencies and have far too little support for making local or per-user installs of a bunch of packages - of course the ideal system would support both, but I can live without global installs more easily than I can live without local installs. I'm lucky already in that the JVM culture is more isolated from the rest of the system - often the only "native" dependency is the JVM itself, and so using the same versions of all jars (and possibly the JVM) will almost always reproduce an issue. My inclination would be to move further in that direction, integrating support for containers or unikernels into the language build tools so that those tools can build executable images that are completely isolated from the host system. > Interference does not happen if you properly isolate the users which is certainly possible on a modern system. > Systemd makes it extremely easy to essentially mount everything but the immediate app data as read-only. No interference. Sure it's possible, but again it's not the natural path, it's not the way the OS or a lot of the traditional-unix tools you get expect it to be. Things like CPU quotas for users feel very bolted-on. > And yes, I need such complex granularity. Why? What does all that extra complexity gain you?