Grouper Users - Open Discussion List

[Tom Barton <>]

Paul,

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.

Tom

Paul Gazda wrote:
> Chris,
>
> 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 
> [mailto:]
> *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.
>
>  
>
> https://bugs.internet2.edu/jira/browse/GRP-199
>
>  
>
> OK?
>
>  
>
> Thanks,
>
> Chris
>
>  
>
> *From:* Paul Gazda 
> [mailto:]
> *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