[drupal-devel] [feature] More granular user management permissions

[budda]

Issue status update for 
http://drupal.org/node/25530
Post a follow up: 
http://drupal.org/project/comments/add/25530

 Project:      Drupal
 Version:      cvs
 Component:    user.module
 Category:     feature requests
 Priority:     normal
 Assigned to:  Anonymous
 Reported by:  budda
 Updated by:   budda
 Status:       patch (code needs work)

Killes: isn't this what the patch is doing already?




budda



Previous comments:
------------------------------------------------------------------------

Wed, 22 Jun 2005 15:50:53 +0000 : budda

Attachment: http://drupal.org/files/issues/accesscontrol.patch (3.48 KB)

When a user role is granted 'administer users' permission this allows
them to not only edit any users profile, but also amend the access
control list, even for their own role. This means a moderator could
actually increase their own permissions to enable further access to
Drupal site settings.


To prevent this I have split the user module permissions further to
provide a new permission setting for each role - "administer
permissions". Enabling this permission for any role will provide the
user with access to the "access control" pages and functionality.


Patch attached to add additional permission and change menu access
checks as needed.




------------------------------------------------------------------------

Wed, 22 Jun 2005 15:56:51 +0000 : nedjo

+1 on idea (I haven't patched and tested), makes sense to me as a
distinct permission.




------------------------------------------------------------------------

Wed, 22 Jun 2005 18:07:51 +0000 : Allie Micka

+1 from me also, although I also haven't tested the patch.  This
"escalate myself" privilege is a big problem!




------------------------------------------------------------------------

Wed, 22 Jun 2005 18:53:46 +0000 : Chris Johnson

+1


This seems like a real requirement for proper permissions handling.


The patch looks good from a code review, but I have not tested it yet.




------------------------------------------------------------------------

Mon, 01 Aug 2005 01:07:30 +0000 : killes at www.drop.org

Attachment: http://drupal.org/files/issues/permissions.patch (3.82 KB)

I've upated the patch to make it work from the root directory. I also
fixed a minor formating issue.


While I think that this patch is usefull, I think it isn't general
enough. Once you got the "admin users" permission you can grant
yourself any defined role. So this patch is only usefull if none of the
defined rules has all permissions. I have a number of sites where this
would be sufficient, but we try to keep Drupal usable for all use
cases. Applying thi spatch as it is now would mean to pretend false
security in a lot of cases.




------------------------------------------------------------------------

Mon, 01 Aug 2005 19:27:55 +0000 : Bèr Kessels

So, what would be ''the'' solution?
* only allow users with a role one ' above' the to-be-changed-user to
change that user? And in that case, how to find the one-above in
drupals non-hierarchical user system,
* only allow users with one role to lever themselves> the patch tries
this, but essentially does not fix the issue. anyone with ''administer
permissions'' can now leverage himself.
* allow only uid1 to dedicate users that can change permissions? which
can be a problem in big environments?


I cannot see any real solution, IMO the *nix solution, the sudo, is the
best one: just introduce a role that can act like uid 1, and leave
permissions to my 3rd solution. 


but in that case this issue whould have to be moved and renamed.




------------------------------------------------------------------------

Mon, 01 Aug 2005 19:51:18 +0000 : killes at www.drop.org

I think a possible solution would be to take "chenge roles" out from the
"administer users" permission and move it to the proposed "administer
permissions" permission. Ie you can only change roles if you can change
permissions. This would make sense to me. People who have "administer
users" permission but not "administer permissions" could still change
other user settings.