emoncms / group

In development: Emoncms groups module
GNU Affero General Public License v3.0
4 stars 8 forks source link

Administrators daisychain #32

Closed cagabi closed 4 years ago

cagabi commented 6 years ago

From Ella's email:

There is a sort of problem with the groups functionality anyway that I haven’t mentioned before. You can daisychain into different accounts if there is more than one administrator, e.g.

Example 1: If I am an administrator of group 1 and Adam is a member then I can get into his account, then if Adam is an administrator of another group, e.g. group 2 , then I can access the members of that group by first accessing Adam’s account, then if any of those members are administrators or other groups then I can get into all those accounts also.

Example 2: If I’m an administrator of group 1 and 2 and Adam an administrator of group 2 and 3, then I can access the accounts in group 3 and Adam the accounts in group 1.

Perhaps it was intended to only have one administrator for all groups, but I think it makes sense that different people can be administrators of different groups, while being members/sub-administrators/passive members of other groups.

Regards,

Ella

cagabi commented 6 years ago

I clearly see the point of this and it's difficult to sort as when you log in as a different user, you fully become the user. A solution I can think is adding the option for a user to tell if the administrator of a group has "full access" to to his/her account or just "feed read access"

takkaria commented 6 years ago

I've just been able to use this to get around access control. Maybe the easiest way to solve this is to disallow impersonating another user if they have administration access to any groups that you don't have access to?

cagabi commented 6 years ago

My previous comment on this was the original thought I had at the designing stage of the groups module to avoid this issue. In fact it wouldn't be that much to finish implementing it as I already put in place what we need. I didn't finish it because it was not part of the specification of the clients.

If you look into the group_users table, there is a column "full_access", in fact you have already seen this around for example when you created the button to "log in as user" where we check that the administrator has full access to the user account before adding the button. The idea is simple, an administrator will only be able to impersonate another user in a group if the full_access flag is true. What there is missing now is the place in the user interface where the user can choose to grant or not full access. Also now by default the full access is true when you add a user to a group (adding as member or creating it new).

So the rule would be that if you are an administrator of a group you never grant full access in the groups you are in. Also it may make sense for somebody to have to users: one with the feeds and data that may want to be shared and another one to admisitrate groups

takkaria commented 6 years ago

Aha! I understand your previous comment better now. Sounds like a good solution.