Considering how we use jails/namespaces and other similar technology, your analogy sounds off. First of all, security is always set up in layers. A different us

Considering how we use jails/namespaces and other similar technology, your analogy sounds off. First of all, security is always set up in layers. A different user and chroot doesn't exclude the use of jails, or other kernel level security systems like AppArmor/SELinux. They are layered on top of each other as necessary. Also, namespaces is not solely a security mechanism. Yes it allows isolation, but it allows resource limitation, too. So you can partition your system to slices and show a particular set of resources to an application (I'm sure you're way more knowledgeable than me in that regard). On the other hand, security starts with application itself. Then you start to add extra containment barriers if you don't trust the software in question. What I understand is our realities are completely disparate, and this is not how we hold the mechanisms I talk about. This might be due to the environment each of us live in, or due to our requirements, I don't know. But, what I know is, the state of security is not as bleak as you portray, and necessity is mother of invention. Except SELinux, AppArmor, and FireJail all of the technologies we talk here are essentially built as virtualization, or virtualization-like technologies. They bring additional security as a secondary effect, and they're good at that. > Software cannot take anything for granted anymore. This is why we have stat calls, defensive programming, APIs and exception handling. The first rule of system programming is to never take anything for granted. I have reached to the end of the time I have for today, Have a nice day and a nice year.