Skip to Content.
Sympa Menu

grouper-users - RE: [grouper-users] rights inheritance ...

Subject: Grouper Users - Open Discussion List

List archive

RE: [grouper-users] rights inheritance ...


Chronological Thread 
  • From: Chris Hyzer <>
  • To: Peter DiCamillo <>
  • Cc: Steven Carmody <>, "" <>
  • Subject: RE: [grouper-users] rights inheritance ...
  • Date: Thu, 5 Feb 2015 22:25:34 +0000
  • Accept-language: en-US

This is fixed.  There are two patches (below) for 2.2.1 from the patcher

 

https://bugs.internet2.edu/jira/browse/GRP-1109

 

There is a demo on the demo server (for people allowed.. right now me, Steven and Peter :) )

 

https://grouperdemo.internet2.edu/grouper_v2_2/grouperUi/app/UiV2Main.index?operation=UiV2Stem.viewStem&stemId=955cb9dbc46740629990fdf265888c89

 

this rule will now fire for creators or stemmers (used to be just creators even though creators is implied by stemmers)

 

the admin UI will now not assign creators when creating a stem (all you need it stemmers)

 

the admin UI will now show create group links if you have stemmers

 

https://github.com/Internet2/grouper/commit/9e9b02df6e4b2219e61c4ad6bdb57a6739968d25

 

Thanks,

Chris

 

[appadmin@i2midev1 patches]$ java -jar grouperInstaller.jar

Do you want to 'install' a new installation of grouper, 'upgrade' an existing installation

  or 'patch' an existing installation

  (enter: 'install', 'upgrade', 'patch' or blank for the default) [install]: patch

Enter in a Grouper temp directory to download tarballs (note: better if no spaces or special chars) [/opt/grouper/2.2/patches]:

What do you want to patch?  api, ui, ws, or psp? [api]: ui

Where is the grouper UI installed? /opt/tomcats/tomcat_d/webapps/grouper_v2_2

What do you want to do with patches (install, revert, status)? [install]:

 

################ Checking patch grouper_v2_2_1_api_patch_0

Patch: grouper_v2_2_1_api_patch_0: was applied on: 2015/01/18 17:45:34

 

 

################ Checking patch grouper_v2_2_1_api_patch_1

Patch: grouper_v2_2_1_api_patch_1: was applied on: 2015/01/18 17:46:04

 

 

################ Checking patch grouper_v2_2_1_api_patch_2

Patch: grouper_v2_2_1_api_patch_2: was applied on: 2015/01/18 17:46:24

 

 

################ Checking patch grouper_v2_2_1_api_patch_3

Patch: grouper_v2_2_1_api_patch_3: was applied on: 2015/01/20 06:07:54

 

 

################ Checking patch grouper_v2_2_1_api_patch_4

Downloading from URL: http://software.internet2.edu/grouper/release/2.2.1/patches/grouper_v2_2_1_api_patch_4.tar.gz to file: /opt/grouper/2.2/patches/grouper_v2_2_1_api_patch_4.tar.gz

Unzipping: /opt/grouper/2.2/patches/grouper_v2_2_1_api_patch_4.tar.gz

Expanding: /opt/grouper/2.2/patches/grouper_v2_2_1_api_patch_4.tar

Patch grouper_v2_2_1_api_patch_4 is low risk, is a security patch

GRP-1109 problems with inherited privileges rule

Would you like to install patch grouper_v2_2_1_api_patch_4 (t|f)? [t]:

 

- added to end of property file: grouper_v2_2_1_api_patch_4.date = 2015/02/04 13:56:11

This patch requires all processes that user Grouper to be stopped.

  Please stop these processes if they are running and press <enter> to continue...

 

Applying file: /opt/tomcats/tomcat_d/webapps/grouper_v2_2/WEB-INF/classes/edu/internet2/middleware/grouper/rules/RuleThenEnum$5.class

Applying file: /opt/tomcats/tomcat_d/webapps/grouper_v2_2/WEB-INF/classes/edu/internet2/middleware/grouper/rules/RuleThenEnum$8.class

Applying file: /opt/tomcats/tomcat_d/webapps/grouper_v2_2/WEB-INF/classes/edu/internet2/middleware/grouper/rules/RuleThenEnum$9.class

Applying file: /opt/tomcats/tomcat_d/webapps/grouper_v2_2/WEB-INF/classes/edu/internet2/middleware/grouper/rules/RuleThenEnum$4.class

Applying file: /opt/tomcats/tomcat_d/webapps/grouper_v2_2/WEB-INF/classes/edu/internet2/middleware/grouper/rules/RuleThenEnum$7.class

Applying file: /opt/tomcats/tomcat_d/webapps/grouper_v2_2/WEB-INF/classes/edu/internet2/middleware/grouper/rules/RuleThenEnum.class

Applying file: /opt/tomcats/tomcat_d/webapps/grouper_v2_2/WEB-INF/classes/edu/internet2/middleware/grouper/rules/RuleThenEnum$1.class

Applying file: /opt/tomcats/tomcat_d/webapps/grouper_v2_2/WEB-INF/classes/edu/internet2/middleware/grouper/rules/RuleThenEnum.java

Applying file: /opt/tomcats/tomcat_d/webapps/grouper_v2_2/WEB-INF/classes/edu/internet2/middleware/grouper/rules/RuleThenEnum$2.class

Applying file: /opt/tomcats/tomcat_d/webapps/grouper_v2_2/WEB-INF/classes/edu/internet2/middleware/grouper/rules/RuleThenEnum$6.class

Applying file: /opt/tomcats/tomcat_d/webapps/grouper_v2_2/WEB-INF/classes/edu/internet2/middleware/grouper/rules/RuleThenEnum$10.class

Applying file: /opt/tomcats/tomcat_d/webapps/grouper_v2_2/WEB-INF/classes/edu/internet2/middleware/grouper/rules/RuleThenEnum$11.class

Applying file: /opt/tomcats/tomcat_d/webapps/grouper_v2_2/WEB-INF/classes/edu/internet2/middleware/grouper/rules/RuleThenEnum$13.class

Applying file: /opt/tomcats/tomcat_d/webapps/grouper_v2_2/WEB-INF/classes/edu/internet2/middleware/grouper/rules/RuleThenEnum$3.class

Applying file: /opt/tomcats/tomcat_d/webapps/grouper_v2_2/WEB-INF/classes/edu/internet2/middleware/grouper/rules/RuleThenEnum$12.class

Patch successfully applied: grouper_v2_2_1_api_patch_4

- added to end of property file: grouper_v2_2_1_api_patch_4.state = applied

 

 

################ Checking patch grouper_v2_2_1_api_patch_5

Patch doesnt exist yet (not an error): http://software.internet2.edu/grouper/release/2.2.1/patches/grouper_v2_2_1_api_patch_5.tar.gz

 

 

################ Checking patch grouper_v2_2_1_ui_patch_0

Patch: grouper_v2_2_1_ui_patch_0: was applied on: 2015/01/18 17:46:18

 

 

################ Checking patch grouper_v2_2_1_ui_patch_1

Patch: grouper_v2_2_1_ui_patch_1: was applied on: 2015/01/18 17:46:20

 

 

################ Checking patch grouper_v2_2_1_ui_patch_2

Patch: grouper_v2_2_1_ui_patch_2: was applied on: 2015/01/18 17:46:22

 

 

################ Checking patch grouper_v2_2_1_ui_patch_3

Patch: grouper_v2_2_1_ui_patch_3: was applied on: 2015/01/18 18:12:10

 

 

################ Checking patch grouper_v2_2_1_ui_patch_4

Patch: grouper_v2_2_1_ui_patch_4: was applied on: 2015/01/18 17:46:30

 

 

################ Checking patch grouper_v2_2_1_ui_patch_5

Patch: grouper_v2_2_1_ui_patch_5: was applied on: 2015/01/18 17:46:31

 

 

################ Checking patch grouper_v2_2_1_ui_patch_6

Patch: grouper_v2_2_1_ui_patch_6: was applied on: 2015/01/18 19:55:29

 

 

################ Checking patch grouper_v2_2_1_ui_patch_7

Patch: grouper_v2_2_1_ui_patch_7: was applied on: 2015/01/20 06:07:59

 

 

################ Checking patch grouper_v2_2_1_ui_patch_8

Downloading from URL: http://software.internet2.edu/grouper/release/2.2.1/patches/grouper_v2_2_1_ui_patch_8.tar.gz to file: /opt/grouper/2.2/patches/grouper_v2_2_1_ui_patch_8.tar.gz

Unzipping: /opt/grouper/2.2/patches/grouper_v2_2_1_ui_patch_8.tar.gz

Expanding: /opt/grouper/2.2/patches/grouper_v2_2_1_ui_patch_8.tar

Patch grouper_v2_2_1_ui_patch_8 is low risk, is a security patch

GRP-1109 problems with inherited privileges rule

Would you like to install patch grouper_v2_2_1_ui_patch_8 (t|f)? [t]:

 

- added to end of property file: grouper_v2_2_1_ui_patch_8.date = 2015/02/04 13:56:19

Applying file: /opt/tomcats/tomcat_d/webapps/grouper_v2_2/WEB-INF/jsp/stemLinks.jsp

Applying file: /opt/tomcats/tomcat_d/webapps/grouper_v2_2/WEB-INF/classes/edu/internet2/middleware/grouper/ui/actions/SaveStemAction.java

Applying file: /opt/tomcats/tomcat_d/webapps/grouper_v2_2/WEB-INF/classes/edu/internet2/middleware/grouper/ui/actions/SaveStemAction.class

Patch successfully applied: grouper_v2_2_1_ui_patch_8

- added to end of property file: grouper_v2_2_1_ui_patch_8.state = applied

 

 

################ Checking patch grouper_v2_2_1_ui_patch_9

Patch doesnt exist yet (not an error): http://software.internet2.edu/grouper/release/2.2.1/patches/grouper_v2_2_1_ui_patch_9.tar.gz

 

Since patches were applied, you should delete files in your app server work directory,

  in tomcat it is named 'work'.  Hit <enter> to continue:

[appadmin@i2midev1 patches]$

 

 

 

From: Peter DiCamillo [mailto:]
Sent: Monday, February 02, 2015 2:18 PM
To: Chris Hyzer
Cc: Steven Carmody
Subject: Re: [grouper-users] rights inheritance ...

 

Sounds good, thanks!

Peter

On 2/2/15 1:16 PM, Chris Hyzer wrote:

I see some issues, though not exactly what you are seeing, let me get a patch to you and we can see if things work then...

 

Thanks,

Chris

 

From: Peter DiCamillo []
Sent: Saturday, January 31, 2015 1:01 AM
To: Chris Hyzer; Steven Carmody; Grouper-Users
Subject: Re: [grouper-users] rights inheritance ...

 

Thanks for the clarification. Until now we've made very little use of folder ACLs, and I wasn't aware that create folder implies create group. It does work that way for me, although I noticed that the admin UI doesn't show the option to create a new group unless you have create group.

Unfortunately, there still seems to be a problem, as shown in the diagram below. As I described before, the ACL-TEST folder, admins group, and CUSTOM folder are set up with the intent that any member of the  admins group has full rights below the CUSTOM folder. At the first level below CUSTOM, user1 creates the level-1 group and folder, and everything is ok. The admin group has admin privileges for the level-1 group and has create folder for the level-1 folder.  After that, user2 creates the level-2 group and folder, and there is a problem. The level-2 folder is ok, but admin privileges for the level-2 group are assigned to user2 instead of to the admin group. As far as I can tell, the reassignGroupPrivilegesIfFromGroup rule uses the create group ACL as the new admin ACL for the group.  The level-1 group would be ok because the CUSTOM folder has a create group ACL. However, since the level-1 folder does not have a create group ACL, no reassignment is done for the level-2 group. I also did testing where the CUSTOM folder did not have a create group ACL, and saw that the level-1 group then had the problem as well.

Peter
ACL
            inheritance diagram


On 1/29/15 9:50 PM, Chris Hyzer wrote:

create group is implied from create folder.  Create folder is like an admin privilege.  When I create a folder I only see CREATE FOLDER being assigned (the others inherited)... is that not the case for you?

 

Thanks,

Chris

 

 

 

-----Original Message-----
From: Peter DiCamillo []
Sent: Thursday, January 29, 2015 4:32 PM
To: Chris Hyzer; Steven Carmody; Grouper-Users
Subject: Re: [grouper-users] rights inheritance ...

 

Thanks. I'm working with Steve, and I've been testing this, with the goal that from below a given folder in the tree, an admin group retains privileges to create and manage additional levels of folders and groups.

I set up a structure like this:

 

ACL-TEST folder

   admins group

   CUSTOM folder

     new-folder

     new-group

 

The ACL-TEST folder has rules for reassignGroupPrivilegesIfFromGroup and reassignStemPrivilegesIfFromGroup. The admins group is given create group and create folder privileges for the CUSTOM folder. With that set up, working as a member of the admins group, I created the new folder and new group under CUSTOM. The admin privilege for the new group was assigned to the admins group, as expected. Also, the create folder privilege for the new folder was assigned to the admins group. However, the create group privilege for the new folder remained assigned to me.

Is that expected? Do I need to do something differently? I did this using Grouper 2.2.1.

 

Peter

 

On 1/26/15 5:49 PM, Chris Hyzer wrote:

> For #1, you just put it on an ancestor stem, you dont have to put it on the substeams, it will inherit.  The rule fires immediately, I believe its in the same transaction as the group or stem create.  Is that what you meant by "cycle".  This use case is what the rule is for, I would use that :)  In general this is what sites generally need, otherwise it is difficult to have multiple local admins and when individuals leave you have a lot of individual privileges pepperred throughout the registry when most of them should have been group privileges.

> Thanks,

> Chris

> -----Original Message-----

> From:

> [] On Behalf Of Steven

> Carmody

> Sent: Monday, January 26, 2015 5:25 PM

> To: Grouper-Users

> Subject: [grouper-users] rights inheritance ...

> Hi,

> we're making a major push giving Depts the authority to create and manage groups within Grouper. Each Dept has an Admins group with privileges within the Dept STEM.

> The default permissions assigned when a group is created, tho, is that the person who created the group gets rights. We want the members of the Admins group to get those rights. They work as a group, and they all need to be able to see and manage the new group.

> We can think of two ways to obtain the outcome we want. But, we're sure we're not the only campus encountering this issue, and we're keenly interested in hearing how other campuses are approaching this problem.

> The two approaches we can think of are:

> 1) use Grouper's Rules functionality. There's a nice example in the Grouper doc:

> https://spaces.internet2.edu/display/Grouper/Grouper+rules+use+case+-+

> Reassign+group+privileges+if+from+group

> This is really clever. Our concern about this approach, tho, is its lack of transparency. You can't see or set these Rules via any known GUI. Its there... but no one in the Depts would ever see the Rules. Also, we don't know on what cycle the Rules would be implemented.

> 2) Use a process outside of Grouper to reset the permissions when a group is created. We're thinking that the Change Log Consumer, when it saw a Create Group Msg, could reach back into Grouper and change the permissions, if appropriate. The Depts wouldn't see this either, but we'd be able to easily see the logic.

> How are other sites dealing with this issue ? Do you have a different approach ? Thoughts on these two ideas -- which would you prefer ?

> Thanks very much !

 

 




Archive powered by MHonArc 2.6.16.

Top of Page