Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] TomB's security view privilege

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] TomB's security view privilege

Chronological Thread 
  • From: Tom Barton <>
  • To: Chris Hyzer <>
  • Cc: Grouper Dev <>
  • Subject: Re: [grouper-dev] TomB's security view privilege
  • Date: Sat, 13 Dec 2008 12:36:19 -0600

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?


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:


*public* *static* *void* internal_addImmediateMembership(

Member m = MemberFinder./internal_findViewableMemberBySubject/(s, subj);


*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.

Archive powered by MHonArc 2.6.16.

Top of Page