Grouper Developers Forum

[Tom Barton <>]

Fair enough. -Tom

Chris Hyzer wrote:
> I think the change to the semantics has already been made... here is the doc 
> in UI for privileges (granted Penn wrote those last spring, but we 
> collaborated with everyone):
>
> https://wiki.internet2.edu/confluence/display/GrouperWG/UI+Terminology
> Read: Entity (typically group or person)  may see the membership list for 
> this group
> View: Entity (typically group or person)  may see that this group exists
>
> So with these as the current documentation, then adding a View-only group to 
> another as member, and thus being able to read the members is a bug.  If not, 
> then I think we need to change that documentation (including tooltips etc).
>
> Im open to someone disagreeing, we can easily add a switch so you can have 
> the previous behavior, though I would be surprised if someone would want 
> this, because then wouldn't READ be similar to VIEW (or maybe VIEW being more 
> powerful since it equals VIEW+READ)?
>
> Anyways, I made this change, and I filter the group search add results in the 
> UI so you don't try to add a group that you cant.  I also changed the 
> addComposite() method of Group.  Unfortunately on the UI the composite 
> left/right dropdown just shows subjects from the workspace, so its not as 
> easy to filter.  If you pick one you can VIEW and not READ, then it will give 
> a somewhat friendly error (Insufficient privileges).
>
> There is also granting privileges to a group/stem, which I made sure was 
> handled.  The one issue which might not be straightforward, is can you remove 
> a membership of a group which you cannot read?  I think the answer is yes, so 
> I left that there (or else you have to ask the grouper admin to do this for 
> you... not what we want).
>
> There might be other cases in the UI where you can search for groups to add, 
> but you should get an error when assigning.  We can work on the usability 
> here...  (security first :) ).
>
> All unit tests pass (including the new ones for this).
>
> https://bugs.internet2.edu/jira/browse/GRP-199
>
> Regards,
> Chris
>
> > -----Original Message-----
> > From: Tom Barton 
> > [mailto:]
> > Sent: Saturday, December 13, 2008 1:36 PM
> > To: Chris Hyzer
> > Cc: Grouper Dev
> > Subject: Re: [grouper-dev] TomB's security view privilege
> >
> > 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.