Security Issue: users with "edit contact" permiss. can add themselfs as admins

[calbasi]

Hi,
Users with "edit contact" drupal permission can add/remove users from groups.
Then, if you have some admin groups (to manage ACL stuff), any user with "edit contact" permission (which is not a very high level permission, because is needed for a lot of simple edition tasks) can add himself to administration groups, which is not desired.
Is there any way to avoid it?
Regards

[Donald Lobo]

edit all contacts is a fairly high level permission the way civicrm is currently designed

acl's typically mean that most users do not have "edit all contacts" and only a few folks do. You might want to review your permissioning structure

lobo

[calbasi]

Hi Donald,

OK, I've notice I can use ACL to let some CiviCRM roles edit users (all, or some groups). But I think the problem persists here... I'd want Editors are able to edit contacts (with Drupal or ACL I can achieve this), but I think they should not assign "control access" groups to users. Why? Because they, then, can assign Administrator or other high level groups to themselves or any other user...

I think a better workflow would be if users with "Edit users" permission, can NOT assign "control access" groups by default (without a specific permission).

What do you think about? 

[Michael McAndrew]

It sounds sensible to me - not sure how easy it would be to implement.  Are you able to put some resources towards it?

[e_mason]

Hitting the same limitation ... ACLs are great except for the fact that staff can add themselves to a group and thus gain any level of permission.  Limiting the ability of staff to edit contacts is a severe restriction.

I would add that being able to ACL group assignment & visibility would remedy this - both because the visibility and operability of groups would be permissioned.  I'd think this has some useful parent-chapter utility as well, reducing the number of visible groups.

The work-arounds I've imagined are putting staff into a contact sub-type and applying an ACL... it can be gotten around, but it can be opaque.  The more extreme version is to add a script to hide the high-level permission group (e.g. "Administrators")  from the drop-down group selectors.  Staff could delete themselves from the group, but not add themselves back in.

That last idea could probably be implemented as a hook as well?  That's probably a lot simpler than going full-permission on groups (since my clients are just figuring out ways to live with it and don't seem interested in sponsoring development).