Issue status update for http://drupal.org/node/25530 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: budda Updated by: nedjo Status: patch +1 on idea (I haven't patched and tested), makes sense to me as a distinct permission. nedjo Previous comments: ------------------------------------------------------------------------ June 22, 2005 - 11:50 : 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.

Issue status update for http://drupal.org/node/25530 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: budda Updated by: Chris Johnson Status: patch +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. Chris Johnson Previous comments: ------------------------------------------------------------------------ June 22, 2005 - 09:50 : 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. ------------------------------------------------------------------------ June 22, 2005 - 09:56 : nedjo +1 on idea (I haven't patched and tested), makes sense to me as a distinct permission. ------------------------------------------------------------------------ June 22, 2005 - 12:07 : Allie Micka +1 from me also, although I also haven't tested the patch. This "escalate myself" privilege is a big problem!

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: Bèr Kessels Status: patch (code needs work) 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. Bèr Kessels 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@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.

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@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@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.

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: JoranLawrence Status: patch (code needs work) I am sort of a newbie to Drupal, so excuse my intrusion in a clearly high-level drupal development discussion. However, I need this functionality for a project and have thought about the issue/problem. While my suggestion might not be a realistic solution (because of the drupal core); it might move the conversation towards one. I think Roles should be able to carry a weight attribute. Reason 1: It could used to print the 'permissions' page of the access control in a logical left to right (less to more) access based on weight. Reason 2: The same logic above would be used so a user could only change permissions for less weighted roles than their maximum assigned role. Reason 3: Users could not assign themselves to roles beyond the weight of their assigned role. I have not looked closely at the code of user.module or the patch, so I don't know how difficult this would be to implement. However, I think this functionality is critical. I would love to see it 4.7. If there is anything I can do to help, please let me know. JoranLawrence 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@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@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. ------------------------------------------------------------------------ Wed, 03 Aug 2005 14:16:30 +0000 : budda Killes: isn't this what the patch is doing already? ------------------------------------------------------------------------ Wed, 03 Aug 2005 14:29:55 +0000 : killes@www.drop.org no. there are no changes to user_edit_form

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: dopry Status: patch (code needs work) from the peanut gallery: +1 on role weighting. +1 to moving change roles to administer permission from user permissions So you could grant a user change role permissions limited by their own role. use case: delegate forum administration to a team member, and allow them to grant/remove forum moderation privileges for volunteer/staff members without uid1 intervention. dopry 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@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@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. ------------------------------------------------------------------------ Wed, 03 Aug 2005 14:16:30 +0000 : budda Killes: isn't this what the patch is doing already? ------------------------------------------------------------------------ Wed, 03 Aug 2005 14:29:55 +0000 : killes@www.drop.org no. there are no changes to user_edit_form ------------------------------------------------------------------------ Wed, 10 Aug 2005 21:19:07 +0000 : JoranLawrence I am sort of a newbie to Drupal, so excuse my intrusion in a clearly high-level drupal development discussion. However, I need this functionality for a project and have thought about the issue/problem. While my suggestion might not be a realistic solution (because of the drupal core); it might move the conversation towards one. I think Roles should be able to carry a weight attribute. Reason 1: It could used to print the 'permissions' page of the access control in a logical left to right (less to more) access based on weight. Reason 2: The same logic above would be used so a user could only change permissions for less weighted roles than their maximum assigned role. Reason 3: Users could not assign themselves to roles beyond the weight of their assigned role. I have not looked closely at the code of user.module or the patch, so I don't know how difficult this would be to implement. However, I think this functionality is critical. I would love to see it 4.7. If there is anything I can do to help, please let me know. ------------------------------------------------------------------------ Sun, 11 Sep 2005 05:58:52 +0000 : moshe weitzman i agree that ordering user roles isa good idea for the reasons you mention. it solves this need in the cleanest way IMO