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: Mon, 15 Dec 2008 08:44:33 -0600

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.





Archive powered by MHonArc 2.6.16.

Top of Page