4 ms·
Just because you don't have more than one "person" user on a system doesn't mean you don't have multiple users. The UNIX security model is based on user separat
by bluejekyll 11y ago
Just because you don't have more than one "person" user on a system doesn't mean you don't have multiple users. The UNIX security model is based on user separation, and has been used in many server environments to define boundaries between different privileges on the system.
Security wouldn't be possible without this. You can also think of cgroups/lxc/docker as a direct extension of this.
- legulere 11y ago> Security wouldn't be possible without this. You can also think of cgroups/lxc/docker as a direct extension of this. I maybe didn't express myself clearly enough. The unix user system wasn't designed for the program isolation it is used for today, but for multi-user systems. The security model was to protect the system from users and users from each other. Cgroups are certainly a move into the correct direction, because it's based on the assumption that programs are evil (either by design, or because they get exploited). When you correctly sandbox programs you won't need to run them as a different user anymore.
- spdionis 11y agoHow much simpler would OSes and security be if we threw away multiple users (and groups)? I think we don't really need them. We only need 3 operating "modes" in 90% of the cases: normal, administrator, guest. And after that various per-application permissions a la Android or iOS. We don't need multi-users systems.
- bluejekyll 11y agoI think multi-user in this context is more about authorization of operations. It's correct that we don't need users/groups for this today, there are equally good things in cgroups and pam, but it's a simpler abstraction in many cases. I think your mostly correct, but in most cases I would prefer individual authorization rules, like apparmor. There's always cases when you don't want to escalate the entire app to root level, but need something more than what's a normal mode.