"Is it just that it's an absolute pain to administer, or is there a deeper problem lurking there?" Deeper problem. Authorization in the general case can not be

"Is it just that it's an absolute pain to administer, or is there a deeper problem lurking there?" Deeper problem. Authorization in the general case can not be done with a set of simple textual tags. Consider sudo. A group might be able to flip on or off whether or not you have generalized sudo, but if I want Bob to be able to run these threes scripts, Betty to be able to run anything as root, and Billy to be able to run this exact script with this regular expression validating the argument, how are you going to do that with groups? Obviously, you can use groups in the solution (each of those names can be replaced with a group identifying a set of people instead of an individual name), but you can't be creating an OS-level group for every tiny fiddly permission that may exist somewhere on the system, especially in contexts where the groups are shared across an organization. Or, to put it another way, yes you could take any arbitrary policy and compile it down into a final set of tag-based permissions, but nobody would want to deal with the resulting thousands/millions of little group tags. It is technically possible but not a win on any level. For example, would you prefer an ACL that says you can access some resource during business hours, or an appearing and disappearing group tag? ACLs and capabilities may suck in some ways, but a quite significant amount of the suckage is fundamental to the problem space. As humans we just don't want to be that specific about security.