This is what I'd agree with. The concept of user and group are hand-me-downs from systems built for sharing networked resources and pretty much requires some kind of centralized AAA to make any sense. They're a model designed for protecting the system from users and users from eachother, but that doesn't make any sense on a personal computer where the more pressing need is to protect the user from malicious applications.
> Running applications as restricted users has been standard practice for decades
...as a way of preventing users from interfering with the system or other users in multi user systems. Running applications as a user different from yourself is an ugly hack we've started doing because we don't have actual control over what our applications can access, so things like ransomware are possible despite not having system level access. Since Plan9 never took off, containerization of applications is the next best thing.
What I'm saying is, running in a restricted user account does absolutely nothing to protect the user running in the restricted account from malicious applciations. That's how the user/group model fails in personal computing.
Once you add backup in the picture, the local users are great. My main account can have all the ransomware it wants, all the backups are gong to stay intact, so I can restore the files.
* in the real life, there is “sudo hole”, but this can be fixed within the current user concept.
And the advent of containerization is becoming standard practice now, precisely because it makes more sense for certain situations, where the user abstraction has proven less useful and more cumbersome. That was the point of this subthread.
I like being protected from writing to /dev/sda by mistake. If an OS is going to expose its guts to the world it makes sense to have permission controls on the vulnerable parts.
Hopefully we won't go back to the Win95/98 era of everything running as single user!
Having services run isolated as their own users is not merely a good security mechanics, it provides for a clear and simple mental model of what is what. A clear permissions barrier that's enforced pretty strictly by the OS.
Moreover we see separate user accounts more and more; even on small devices like phones it makes sense to have, for example, separate "private" and "business" accounts.
>does that mean processes have failed?
Nah, that's too general of a take. There are two more specific failures. First up, people fail to realize the present-day crop of containers are re-inventing processes. "Those who do not learn history, etc, etc."
Secondly, there's a significant failure of certain key features (like IP stack, FS handlers, etc. - in general, NAMESPACES) having been provided almost exclusively in kernel, and thusly requiring either superuser access or complex work-arounds (like FUSE) to manage. Plan 9 did it the right way; on P9, processes == containers.
But having separate private and personal accounts on your phone is very different from application resource namespacing. They're essentially orthogonal concerns.
In the case you're making, a user (a real actual human user) has different settings when _using_ the phone in two contexts. In the latter case, applications are restricted to sandboxes with well-defined interactions between each other's memory, processes, devices, sockets, and files.
So, you run three different Gmail accounts in chrome, and two different office 365 logins in Firefox. Not only can the firefox process, under you user ID, read/write chrome's cache, local data etc and vice versa, but so can your calculator app, your cpu temperature widget and your solitaire game.
Lxc can improve a bit on this, as can "containers" (lxc or otherwise restricted processes).
And resource sharing these days for SaaS and PaaS either occurs on the hypervisor level or the application level — the (usually Linux) OS is seen as a liability and necessary dependency for the application rather than a secure environment.
Also, current isolation technologies on desktop tend to be a lot less secure than mobile. If you assume Fuchsia, Android, iOS to be the next generation of OSes, then the trend is definitely to "secure by default". Whitelisting permissions instead of everything being allowed out of the box. Even the current generation of Linux containers is more of a bunch of resource management hacks, compared to e.g. hypervisor sandboxing or to a lesser extent, BSD jails.
Not really, for shared ressources, it was not that long before realizing that isolation was necessary for memory, storage has been has been managed via fs with rights since sharing files between processes is handy, shared networking as been a problem from day 1 (port numbers assignation).
Container just homogenise the paradygm for all resources: strict isolation by default, else explicit sharing.
A container _is_ a process, just with cgroups associated to it on startup so it has no visibility of other processes in the system (aka. is sandboxed).
So no.. processes haven't failed. Anything that runs on your system is or is part of a process.
Containers run processes, in a context where those within a container only see those within the same container, by underlying OS accounting generalization.
Containers aren't even a thing like that though. They don't run anything per se. Implementations vary but it can be as simple as an extra struct field in the process list.