Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

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

fixed in 2.3.0 ui patch #13.
Note, both issues are fixed.

Thanks,
Chris

-----Original Message-----
From: Chad Redman (JIRA) 
[mailto:]
 
Sent: Thursday, November 17, 2016 11:12 AM
To: Hyzer, Chris 
<>
Subject: [JIRA] (GRP-1418) removeMembers redirect to main page for non-wheel 
user with Admin priv but not update


    [ 
https://bugs.internet2.edu/jira/browse/GRP-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24170#comment-24170
 ] 

Chad Redman commented on GRP-1418:
----------------------------------

There is a similar issue in the same method, with privilege checking for 
recentlyUsedMemberAdd() and recentlyUsedGroupAdd(). But the issue I noted 
above where the removal does not appear in the recent activity is not from 
this, but is from the audit log. The audit log is logging the removal as 
being done by GrouperSystem, so it shows up under GrouperSystem's activity. 
That's currently as intended; removals are done as GrouperSystem in case the 
logged in user itself is removed. But it would be a useful enhancement to 
show removals in the user's activity.


> removeMembers redirect to main page for non-wheel user with Admin priv but 
> not update
> -------------------------------------------------------------------------------------
>
>                 Key: GRP-1418
>                 URL: https://bugs.internet2.edu/jira/browse/GRP-1418
>             Project: Grouper
>          Issue Type: Bug
>      Security Level: Standard(Standard bug, may impact functionality but 
> does not represent a security vulnerability) 
>          Components: UI
>    Affects Versions: 2.3.0
>            Reporter: Chad Redman
>            Assignee: Chris Hyzer
>
> When removing users using the "Remove selected members" button, the 
> behavior is different between wheel users and non-wheel users with an admin 
> privilege on the group. For a user that has admin privilege, but not an 
> explicit update privilege, removing selected users will redirect the user 
> away from the group to the site home page.
> h3. Steps to reproduce
> # Load the sample quick start data
> # Log in as GrouperSystem
> # Create Group qsuob:test:AdminAccess
> # Don't grant anything to EveryEntity
> # Grant admin to babe (Barry Benson)
> # Add bawi (Barry Windsor) as member
> # Add "babe" to the tomcat-users.xml if needed
> # In a different browser, login as "babe"
> # Go to qsuob:test:AdminAccess
> # Select checkbox for Barry Windsor
> # Click Remove Selected Members
> h3. Result:
>   - Flash status "Success: removed 1 members"
>   - Redirected to UiV2Main.indexMain (the home page)
>   - Doesn't show change under recent activity (a separate issue?)
> Note that explicitly adding the Update privilege for the user avoids this 
> result, and it remains on the group page.
> h3. Analysis
> The source code for UiV2Group.removeMembers has this code which seems to be 
> the immediate cause (correlated to the difference in Ajax response between 
> wheel and admin):
> {code:java}
>       if (!group.hasUpdate(loggedInSubject) || 
> !group.hasRead(loggedInSubject)) {
>         
> guiResponseJs.addAction(GuiScreenAction.newScript("guiV2link('operation=UiV2Main.indexMain')"));
>       } else {
>         filterHelper(request, response, group);
>       }
> {code}
> For users with the Admin privilege, privilege management in the UI shows a 
> black checkbox for Admin, and also grey checkboxes for all the other 
> privileges, including Read and Update. That would imply there is an 
> inheritance of these privileges for admin. However, 
> group.hasUpdate(loggedInSubject) and group.hasRead(loggedInSubject) are 
> false for a user with just the Admin privilege.
> My guess for a fix is to add 
> {code:java}
> || !group.hasAdmin(loggedInSubject)
> {code}
> to the conditional above. But there may be nuances in the privilege system 
> I'm not aware of.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)