Major Description
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).
Regards,
Chris
> ----Original Message----
> From: Tom Barton
> 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.