Grouper Developers Forum

[Tom Barton <>]

I think that, with clarity of hindsight, grouper implementation didn't 
faithfully follow intended design with regard to VIEW. VIEW is supposed 
to mean you can see the group and refer to the group (and hence to its 
members). Now that we've seen the difficulties with managing memberships 
at large scales, the intended design probably can't work at all well. 
Too much checking, unless each membership record carries with it the 
Access privs of the group giving rise to that membership, or something 
like that.

From that perspective it's reasonable to consider altering the 
semantics of VIEW to keep just the "see" part but jettison the "refer 
to" part. That would mean you'd need READ to add a group to another, and 
Chris's suggestion below would be one change needed.

Would there be other changes also needed?

Do folks feel that we should make this alteration of the semantics of VIEW?

Tom

Chris Hyzer wrote:
> Im thinking about the security issue, and I was wondering if you could 
> elaborate a little more in an email a little more about why changing this:
>
> FROM:
>
>   *public* *static* *void* internal_addImmediateMembership(
>
> …
>
>       Member    m   = 
> MemberFinder./internal_findViewableMemberBySubject/(s, subj);
>
> TO:
>
>   *public* *static* *void* internal_addImmediateMembership(
>
> …
>
>       Member    m   = 
> MemberFinder./internal_find*_Read_*ableMemberBySubject/(s, subj);
>
> Would not be desirable?  Originally I had though it weird if the session 
> doing the assigning once had READ, then made the membership, then they 
> lost READ, but then I am thinking it is like other cases where the 
> membership would still exist, they just wouldn’t be able to add it to 
> another group.  This sounds fine with me…
>
> **New Action Items**  
>
> [AI] (TomB) will create a JIRA issue related to documenting security 
> issues, such as view privilege potentially leading to read.