4 ms·

Interesting insight from the linked thread: “Short-sighted - users and groups. It makes sense on a single-host system being shared at a university. It is weak

by haolez 8y ago

Interesting insight from the linked thread: “Short-sighted - users and groups. It makes sense on a single-host system being shared at a university. It is weak for pretty much any other setting. It acts as a distraction in pretty much every setting where we now use unix: on personal systems, on cloud deployments, in the enterprise. There are constant hassles of aligning users and groups between systems, and ensuring that applications are structured along those lines. To offer an alternative. We would be in a better place if unix provided some kind of standard process-group sandboxing, along the lines of jails. Permissions would be applied at the jail level rather than the filesystem level. The sandboxes in smart-phone OSs hint at the way.” I feel this pain in some cloud deployments, but I’ve never thought about the whole users and groups concepts as the core of this issue.

jimktrains2 8y ago
Isn't that what cgroups are in Linux? Not jails in the bsd sense, but a way of grouping processes and setting specific ulimits and other permissions?
- xemdetia 8y ago
  It is a layer of abstraction that helps the application piece but I wouldn't say it solves the real problem being mentioned. That problem is closer to top level uid management. When you are working with 50k systems and have to deal with things like "because there was a slight deviation of install order tomcat is uid 105 on one system and 106 on another set of systems, some tarballs are screwed and need a second perm pass otherwise they'll come up as owned by a different user." And while there are ways to improve this with LDAP and things on Linux covered by nsswitch and so on, they just aren't very nice. And because so much is driven by uid internally finding that one system out of 100 where a constraint is violated is needlessly troublesome, compare this to Windows and AD where at any moment there is always a clear source of truth. Cgroups fixed that in the local space but just having a clean logical mapping that is consistent across all implementations where things are wholly separate by default and there is no bleeding in of the parent OS like a VM does
AnIdiotOnTheNet 8y ago
At least for a personal system, when you frame the problem correctly it becomes obvious: Is your goal to protect the system from its user, or protect the user's data from applications? User and group oriented security only makes sense for the former.

by haolez 8y ago

jimktrains2 8y ago

Isn't that what cgroups are in Linux? Not jails in the bsd sense, but a way of grouping processes and setting specific ulimits and other permissions?

xemdetia 8y ago
It is a layer of abstraction that helps the application piece but I wouldn't say it solves the real problem being mentioned. That problem is closer to top level uid management. When you are working with 50k systems and have to deal with things like "because there was a slight deviation of install order tomcat is uid 105 on one system and 106 on another set of systems, some tarballs are screwed and need a second perm pass otherwise they'll come up as owned by a different user." And while there are ways to improve this with LDAP and things on Linux covered by nsswitch and so on, they just aren't very nice. And because so much is driven by uid internally finding that one system out of 100 where a constraint is violated is needlessly troublesome, compare this to Windows and AD where at any moment there is always a clear source of truth. Cgroups fixed that in the local space but just having a clean logical mapping that is consistent across all implementations where things are wholly separate by default and there is no bleeding in of the parent OS like a VM does

AnIdiotOnTheNet 8y ago

At least for a personal system, when you frame the problem correctly it becomes obvious: Is your goal to protect the system from its user, or protect the user's data from applications? User and group oriented security only makes sense for the former.