More flexible rights management?

Via Planet PHP comes this interesting tidbit from Markus Wolff, the original author of PEAR LiveUser. After briefly lamenting over-engineered ACL (access control list) systems in PHP, he talks about a much simpler concept that holds some interesting nuggets of joy. Might Drupal benefit from some of them?

His basic concept is actually very similar to Drupal's user_access() based permission system now. The key difference is that Drupal's system is flat natural-language terms (well, sort of) while the one Markus proposes uses nested, technical language terms. However, being nested gives it one very useful feature that Drupal's system lacks: wildcards.

One rather major failing of Drupal's access system right now is the "administer X" permissions. They are, almost universally, so broad as to be considered a security risk. "administer users" is by far the worst, as it means that "edit other users", "approve new user applications", "configure user roles", "delete users", "change password for any user", and "view blocked users" are all the same permission. That is, you cannot give someone access to process applications without giving them the ability to take over or delete the administrator account. That we still have that configuration is, honestly, embarrassing.

OK, but now consider if we had a permission structure like:

• User.Accounts.EditAccounts
• User.Accounts.ChangeAnyPassword
• User.Accounts.ProcessApplications
• User.Accounts.ViewBlockedAccounts
• User.Permissions.ConfigurePermissions
• User.Permissions.ConfigureRoles

(Or maybe instead of . we should use \, which from PHP 5.3 onward is the symbol for namespace? Hmmm...)

Then we could assign or check permissions with a very fine grain. If we wanted to grant someone "administer users", we would instead grant "User.Accounts.*", which gives them all account management access but not to change what roles could do what, or global User.* access, or whatever we wanted. Conversely, instead of having to check each permission separately we could check if someone had User.Accounts.*, that is, if they have at least one permission under User.Accounts. Then we'd know to, say, show the "User management" admin menu item.

But wait, aren't those permissions less readable than our current natural language ones? Well, sort of. The current permissions are not always intuitive, which is actually why as of Drupal 7 they now have full-text descriptions and translatable titles. The underlying permission string itself is no longer user-exposed, so we can change the string itself to whatever we want.

Of course, there's still the question of efficient implementation. We'd need the proper SQL format to make permission checks as fast and efficient as they are now, or at least close to it. However, I'm sure that is a solvable problem if someone put their mind to it.

Of course, this addresses only action-based permissions, not object-based permissions (which are currently addressed by the scare-fest that is the node_access system). Still, it could be a straightforward but major improvement to our underlying access control system in Drupal 7 if someone wanted to pick it up.

Think about it; a natural hierarchical structure would also allow modules to inject permissions into any category, rather than just grouped by module, and would inform vastly improved UI concepts on the "field of checkboxes" permissions page. What if it was a nested tree by category? Or each top-level category had its own tab, which would then have a smaller set of checkboxes on it grouped by sub-category? There are plenty of possibilities here.

So who wants to make Drupal 7's permission system far more flexible? I so totally don't have time to work on it myself, sadly, but there's a lot of potential here for short- and long-term improvement. Who wants it? :-)