Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] RE: Access privileges within sub-groups and composite groups

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] RE: Access privileges within sub-groups and composite groups

Chronological Thread 
  • From: Tom Barton <>
  • To: Paul Gazda <>
  • Cc: Chris Hyzer <>, Grouper Users Mailing List <>
  • Subject: Re: [grouper-users] RE: Access privileges within sub-groups and composite groups
  • Date: Thu, 09 Apr 2009 17:06:00 -0500


Regarding your first point, there is a major downside - the performance hit that would accompany implementing your proposal. Evaluating privs per membership, across an arbitrarily complex web of groups, will be far costlier than doing so at the group level, as at present.

So, as a pragmatic matter, rather than as a conceptual matter, I have trouble with your proposal. To achieve the purpose with reasonable performance sounds like an allocation of project resources that would seriously reduce our ability to deliver more important capabilities.

Regarding your second point, some time back we fixed the *bug* of VIEW being sufficient to add a group to another group. That allows anyone with VIEW to gain READ, in effect, by creating an empty group, then adding a group for which they only have VIEW as a member, then looking at the indirect members.


Paul Gazda wrote:

Thanks for your reply, although it is not what I was hoping to hear. J From the jira, it appears that there were technical factors contributing to the decision, and I realize that the issue of changing permissions on subgroups presents dilemmas no matter how you handle it. However, I do want to present arguments for having Grouper dynamically honor access permissions when displaying query results, and allowing subgroups with view privileges to be added.

First, dynamic evaluation of permissions. If a person creates a group with “read” access to GrouperAll, and other people incorporate it into their groups, and then the person changes access to “view” for GrouperAll, they would intuitively expect from that point on, that people would not be able to see the members of that group. They would not be thinking that the previous read privilege would be grandfathered into all groups that currently have it as a subgroup. If the burden is placed on the business logic of the UI, it could generate a lot of overhead for the admin user behind the scenes to look for all groups that contain the subgroup and delete it from all of them. That could be a very time consuming operation using web service calls.

I also see an advantage of allowing subgroups to be added when the user has only view access. For example, some standard groups may be provided to users such as all students, all staff, all faculty, etc. that may have thousands of members. If everyone needs read access to use them as subgroups, they will be able to query the members, and curiosity being what it is, many people will be bogging down response time by needlessly listing the thousands of members. The UI will have to prevent those kinds of queries via business logic, which probably means both special group design and special coding to recognize and suppress the querying of those special groups. It would be much simpler from a development point of view if Grouper returned only the group name to a user who had only view privilege at the time of the query.

Paul Gazda


*From:* Chris Hyzer
*Sent:* Wednesday, April 08, 2009 12:05 PM
*To:* Paul Gazda; Grouper Users Mailing List
*Subject:* RE: Access privileges within sub-groups and composite groups

That was a design decision…

If you add a group’s members to your group while you have read access, then that group “has” those members, and can always query for them if you can list the outer group’s memberships. However, if you remove that group from your group, then you wont be able to re-add it without READ of the underlying group.

So… if you are removing READ from a group, and you want to make sure no one is using that list, you should check to see where that group is a member of another group or a composite factor…

We did discuss this on a design call, but this exact issue didn’t make it into the Jira issue, I added a comment.




*From:* Paul Gazda
*Sent:* Wednesday, April 08, 2009 2:55 PM
*To:* Grouper Users Mailing List
*Subject:* [grouper-users] Access privileges within sub-groups and composite groups

I am seeing what seems to be an inconsistency in the way Grouper handles access privileges in sub-groups and composite groups. I have looked in the listserv archives and wiki and could not find info on this. I see the same behavior in both cases and will explain it with a sub-group example.

I have a group A.

I have a group B.

I make group B a sub-group of group A.

I query for the members of group A using getMembersWs of GrouperClient 1.4.1 as a non-admin. I see all of Group A’s members plus Group B plus Group B’s members - as expected.

I remove read and view access privileges on Group B for GrouperAll.

I query for the members of Group B and get an error that the group is not found – as expected.

I query for the members of Group A and see all of Group A’s members plus Group B plus Group B’s members. That is not what I would expect. I would expect to see only Group A’s members because Group B should still be invisible to GrouperAll.

Paul Gazda

Archive powered by MHonArc 2.6.16.

Top of Page