3 ms·
No, I believe that misses my original point. cgroups and namespaces are privileged mechanisms that only 'root' can use, and share UIDs and other scopes across
by zbuf 6y ago
No, I believe that misses my original point.
cgroups and namespaces are privileged mechanisms that only 'root' can use, and share UIDs and other scopes across them (UID namespaces are complex and a risk in themselves.) It's required to re-implement all the required policy.
Separate UIDs need get no more confusing than PIDs. I agree we really don't want /etc/passwd with a gazillion entries; we should only be managing them only as much as we "manage" temporary PIDs. But imagine a command to view the "UID" tree like the PID one.
I agree it might not be how we'd design it if we designed from scratch. But then we may have chosen cgroups that integrated into the process tree and several other design decisions would change.
The name "user" ID distorts the conversation because it's unintuitive, but I am suggesting that UIDs already embody much of the policy that is needed.
- CountSessine 6y agoThis is kind of what android does with selinux. Every app you install gets assigned a new UID on install. It seems to work quite well. Maybe we need this everywhere?
- wtallis 6y agoWe do, potentially with some modifications to make it easier for applications to interact with each other in novel ways once the user grants permission. Mobile operating systems are far ahead of desktop operating systems when it comes to making the "application" a first-class entity. macOS comes closest since most ordinary applications can be largely self-contained within the app bundle and the sandbox is steadily getting richer protection/isolation mechanisms. Linux applications have fairly well-controlled install and uninstall processes thanks to distro package managers, but post-install behavior cannot be managed with application granularity in any standard way (though there are some projects seeking to accomplish this, if they can first succeed in replacing existing distro package managers). And Windows is still largely allowing applications to spray files all over the disk and run whatever in the background. The challenge for the desktop is that we don't really want to switch from a multi-user paradigm (with all applications in the same security domain) to a single-user paradigm with per-application security domains. We need a multi-user OS with per-application security domains, and mobile operating systems aren't quite there. (I've heard that Android can be multi-user, but I've never encountered that functionality in the wild.)