Grouper Users - Open Discussion List

[Chris Hyzer <>]

Well, if you give someone READ on a group, then they have that data.  Whether 
they allow others to READ a container group inside of Grouper, they will 
still be able to use/expose that data in a different way, right?  I think 
good defaults help so bad things aren't done unwittingly, i.e. not have 
global READ on by default...  Grouper Rules will make it easier to sync a 
group (you have READ on) with another group (you have ADMIN on), so Im not 
sure checking underlying objects is a lot more secure, right?

But yes, I agree with you, that you should only grant READ to sensitive data 
to a manageable number of users who you trust to not distribute the data.  I 
think you can have a large number of users in Grouper, but you should tightly 
manage your access lists.  KualiRice/Grouper workflow for access forms where 
users read and agree to acceptable use policies help when they get access to 
sensitive data (in this case, membership lists)

If you have a composite minus, or intersection, then you might not want to 
grant READ of the underlying groups, and just grant on the overall group so 
you don't expose more data right?  And if you mix composites with groups 
having group memberships it would get more complicated to compute.

Do you have a use case which is not possible with the current design?

Thanks!
Chris



-----Original Message-----
From: RL 'Bob' Morgan 
[mailto:]
 
Sent: Thursday, January 13, 2011 2:08 PM
To: Chris Hyzer
Cc: Jim Fox; grouper users list
Subject: RE: [grouper-users] read permission and effective membership


Wow.  If I understand this correctly, it is surely a triumph of 
convenience over security.  If I set access control on a group, anyone who 
has read access to that group can effectively change that access control 
by including that group in some other group, right?  This seems to be 
justifiable only if the groups system is being used by a small set of 
trusted users.

  - RL "Bob"

On Thu, 13 Jan 2011, Chris Hyzer wrote:

> Yes.  We had a lot of discussion on this point.  There are pros and cons 
> either way, but the way it is implemented had a better score  :)
>
> Some notes on the topic:
>
> If two people query the same group, and get a response that they have READ, 
> then they should have consistent results
>
> It is a lot more scalable this way, rather than having to check permission 
> on all descendent groups.  One important aspect of the Grouper code is 
> being able to do DB operations in one query, not multiple queries.
>
> If someone gets rights to read a group, but not read a member, but they 
> should have it, then it will be hard to communicate that to the user.  They 
> will just see a partial listing with no warning about it
>
> This is similar to Oracle security with GRANT option... i.e. if you have a 
> view on a table, and you grant access to the view, then I don't think the 
> querier needs SELECT on the underlying table...
>
> Thanks,
> Chris
>
> -----Original Message-----
> From: 
> 
>  
> [mailto:]
>  On Behalf Of Jim Fox
> Sent: Thursday, January 13, 2011 10:42 AM
> To: grouper users list
> Subject: [grouper-users] read permission and effective membership
>
>
> I have a user 'u' and two groups 'a' and 'b'.
>
> 1) 'u' has Read permission on 'a'.
> 2) 'u' does not have Read permission on 'b'
> 3) 'b' is a member of 'a'.
>
> If 'u' does a getMembers() on group 'a' it sees all the effective
> members, including those of 'b'.  Is this the expected behavior?
>
> Jim
>
>