3 ms·

It simply shows that Unix predates modern requirements towards operating systems. There's no unified privilege hierarchy with capabilities. The only vertical is

It simply shows that Unix predates modern requirements towards operating systems. There's no unified privilege hierarchy with capabilities. The only vertical isolation Unix offers is userspace vs. kernelspace and root vs. other users and for vertical isolation it's different users (which are abused, as daemons don't really belong to a user) and processes. Because of modern requirements features that already exist get abused (vertical isolation of daemons through different users) and new features get tacked onto already existing ones. This leads to very complicated code-paths that are bug-prone for privilege escalation. Users already offer horizontal isolation similar to containers that sit next to each other. But instead of making users more general they are half-emulated in containers. The way which taken to fix this is by adding even more complexity, so I guess it will take long until we will come to a point where linux containers are reliable.

taeric 12y ago
I'm curious what the main downside to using multiple vms for this is. Seems like a simpler system, all told. Sure, they are bigger parts, but they are much more cleanly defined in how they interact with each other. That is, finding ways to isolate applications on one machine from each other, while sharing the same resources, just flat out sounds difficult. That two applications can have different /etc/hosts files, for example, just doesn't really grok that easily. That two machines could have this is easy.
- legulere 12y ago
  Well you have to emulate almost the whole hardware in software when doing virtual machines. This costs lots of performance (less so if you do paravirtualisation). A virtual machine software essentially is an operating system that offers emulated native hardware as an interface. You don't have to show both applications the same file, you can mount different filesystems for them for /etc/ for instance. Or maybe the applications shouldn't read /etc/hosts directly
  - taeric 12y ago
    So, /etc/hosts is just a silly example. One that happens to be easy to consider. You want "backend" for one service to be a different machine than "backend" for another. (Again, simple example, not necessarily indicative of how things should be.) But, this really doesn't answer my question. Sure, emulating a full machine can be expensive. That is typically why you do it with a very powerful machine in the first place. If the losses are such that they are causing problems, you can always go to real hardware, even. More to the point, this implies that containers are somehow "free." I am skeptical that could be the case. You are adding a whole new layer onto the operating system to possibly present multiple copies of files or only subsets. Simply put, there can be no free lunches. The price is paid somewhere.
    - laumars 12y ago
      Containers don't require a whole new layer since you're effectively using the kernel as a hypervisor. Very simplistically put, containers are a little bit like chroot processes - so a guest would have it's own /etc directory unique to the host (you don't need to build containers this way if you don't wish to, but this would be the standard type of set up). With LXC, the guest processes are separated via cgroups, which is the same way systemd separates processes on the same host during it's init.
      - taeric 12y ago
        For some reason, I just can't get past the thought that this overhead is more than just a little. And, again, my main concern is more of a cognitive one. It is fairly hard to "pull back the curtains" and think about a system that has different /etc files for each application/container on it. (Heck, the implication seems to be that it would be possible for malware to somewhat easily hide stuff from the other users on the machine.) I mean, I realize it can be done. And pretty soon it would become the more standard way to do things. Just seems a larger mental shift to me than you are making it sound.
        laumars 12y ago

taeric 12y ago

I'm curious what the main downside to using multiple vms for this is. Seems like a simpler system, all told. Sure, they are bigger parts, but they are much more cleanly defined in how they interact with each other. That is, finding ways to isolate applications on one machine from each other, while sharing the same resources, just flat out sounds difficult. That two applications can have different /etc/hosts files, for example, just doesn't really grok that easily. That two machines could have this is easy.

legulere 12y ago
Well you have to emulate almost the whole hardware in software when doing virtual machines. This costs lots of performance (less so if you do paravirtualisation). A virtual machine software essentially is an operating system that offers emulated native hardware as an interface. You don't have to show both applications the same file, you can mount different filesystems for them for /etc/ for instance. Or maybe the applications shouldn't read /etc/hosts directly
- taeric 12y ago
  So, /etc/hosts is just a silly example. One that happens to be easy to consider. You want "backend" for one service to be a different machine than "backend" for another. (Again, simple example, not necessarily indicative of how things should be.) But, this really doesn't answer my question. Sure, emulating a full machine can be expensive. That is typically why you do it with a very powerful machine in the first place. If the losses are such that they are causing problems, you can always go to real hardware, even. More to the point, this implies that containers are somehow "free." I am skeptical that could be the case. You are adding a whole new layer onto the operating system to possibly present multiple copies of files or only subsets. Simply put, there can be no free lunches. The price is paid somewhere.
  - laumars 12y ago
    Containers don't require a whole new layer since you're effectively using the kernel as a hypervisor. Very simplistically put, containers are a little bit like chroot processes - so a guest would have it's own /etc directory unique to the host (you don't need to build containers this way if you don't wish to, but this would be the standard type of set up). With LXC, the guest processes are separated via cgroups, which is the same way systemd separates processes on the same host during it's init.
    - taeric 12y ago
      For some reason, I just can't get past the thought that this overhead is more than just a little. And, again, my main concern is more of a cognitive one. It is fairly hard to "pull back the curtains" and think about a system that has different /etc files for each application/container on it. (Heck, the implication seems to be that it would be possible for malware to somewhat easily hide stuff from the other users on the machine.) I mean, I realize it can be done. And pretty soon it would become the more standard way to do things. Just seems a larger mental shift to me than you are making it sound.
      - laumars 12y ago