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: Chris Hyzer <>
  • To: Tom Barton <>
  • Cc: Grouper Dev <>
  • Subject: RE: [grouper-dev] TomB's security view privilege
  • Date: Mon, 15 Dec 2008 03:17:12 -0500
  • Accept-language: en-US
  • Acceptlanguage: en-US

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):
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).


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

Archive powered by MHonArc 2.6.16.

Top of Page