grouper-users - [grouper-users] Global readers on folders unable to create groups
Subject: Grouper Users - Open Discussion List
List archive
- From: Marwan Shaher <>
- To: "" <>
- Subject: [grouper-users] Global readers on folders unable to create groups
- Date: Tue, 15 Sep 2020 17:31:23 +0000
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=colorado.edu; dmarc=pass action=none header.from=colorado.edu; dkim=pass header.d=colorado.edu; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yETfee+Xeypyj4EJa25fGeW8dOOdMpDQVoPtaEqtaH4=; b=QM8zlS9DZfLBjC28rM1PV/qdKcJ/xvFAjxG5v58oO7Filkx3PMSxR5IpsWhGBIw9iJA9xkTnBxPbFB6VJlY1NamrlMV3mcDrWC/aJwzWtK0Z8oKQluZWcs9d4s8XRDHhn3NyG8nnYx6JgHiU8zsqxXn6bHv/czRw2W39Z6TBE2TOmUHlx9jwYmTKxTDRZm3qlU9TY5jUZHjJ8jfkcIQYQxfH3bsve7Q4nbMucn1gFLI07fC2RDjLInVvcYNPDcKiDQjgvrTIIKZBmPaXZbtp9ymyxiLAUu8XDGO880J+yW5/Xfxsdz2Ldta4cJXrCOoZjb3XUwK/vSb1QP7m8dVeAw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m52c0q/uS13AxqnaZ6vLjA37Phxx/wMjfyeqQ3cm4QFluWgc/fiqPZBWN2WjuSamxXwlmncU689iTP3FkDJGIjEZ5IaJxXEdo/11G454HHeMVyx7j7NrOrXegsOJ0newrEpFoSOBIqXQZegs4nXkp+kNFeyvYB+YxZ8SskGcesqfXRvanafWwm/R+XtmqPNVCin0pDgbWjb5Ye7XeDGAGnvIYoDbSqWaNYkm7YAx8H+5f4n2z29zcGRp44YBTieTIW91/jZ2ZgHHjqy2dNnmCBrWiJSzJfQ3MgdQeqzKaAFDm+pgrdu8CK8aSxvPhlipHzxnZJ8usD3PkbQYlFsPTg==
Hello All,
Apologies for the long email in advance. We have an inherited privilege setup on the “Root” folder/stem so that members of the custom group “etc:sysadminReadersGroup” have the “View” and “Read” privileges granted to them for all objects in the
folder and subfolders. This was setup a while back and serves as our global readers group. Members are added on a need-to basis and only if they meet certain criteria (e.g: took FERPA training) . It worked well for us until we stood up new UI nodes running
in Docker containers that would replace the standalone UI nodes. The issue we noticed is as follows:
Accounts that are
- members of “etc:sysadminReadersGroup” by "two or more ways"
AND
- have admin or create privileges on any folder,
can no longer create groups in said folder, if their UI session is on the nodes running in containers. “two or more ways” means that they are either both direct and indirect members of “etc:sysadminReadersGroup” or indirect members because of
their memberships in 2 or more groups that are nested into “etc:sysadminReadersGroup”. New group creation is the only thing affected. Other functions like membership update or group deletions are successful as long as the accounts has the necessary rights
to do so.
Everything works fine as expected if they are on the standalone UI nodes, or if they are on the container nodes with effectively one direct or indirect membership in “etc:sysadminReadersGroup”.
The users would encounter the following error in the scenario described above:
— begin: UI error ---
Error creating group: Why is there more than one membership found? memberIds: ArrayList size: 1: [0]: 1f4f3d4f286143ffa7df6883c081b171 fields: HashSet size: 1: [0]: Field[name=members,readPrivilege=read,
type=list,uuid=f1446f9d48af4e8d965...groupIds: ArrayList size: 1: [0]: af68b3f82448484fa1a3cb6d9f675981 , Problem in HibernateSession: HibernateSession (4b876527): notNew, notReadonly, READ_WRITE_NEW, activeTransaction, session (557b7b5b), Problem in HibernateSession:
HibernateSession (1cad972b): new, notReadonly, READ_WRITE_NEW, notActiveTransaction, session (557b7b5b), Problem saving group: Training:test_0987, thread: 213f2ed7
— end: UI error —
The logs from the container’s grouper_error.log are similar to the above with more detailed java trace error information, mainly :
at edu.internet2.middleware.grouper.MembershipFinder.findMembership(MembershipFinder.java:985)
at edu.internet2.middleware.grouper.rules.RuleApi.inheritedRulesForFolder(RuleApi.java:530)
at edu.internet2.middleware.grouper.rules.RuleApi.inheritedRulesForFolderOrCache(RuleApi.java:463)
at edu.internet2.middleware.grouper.rules.RuleApi.access$100(RuleApi.java:57)
….
….
The UUID in the line above: "ArrayList size: 1: [0]: af68b3f82448484fa1a3cb6d9f675981”
<— references the UUID of “etc:sysadminReadersGroup”
The same behavior can be replicated on a smaller scale, ie, without assigning the inherited privilege on the “Root” folder. If the same inherited privilege is assigned to any other folder where any group (e.g: myCustomReaders)
is given “View” and “Read” privileges granted to it for all objects in the folder and subfolders AND accounts have “Admin” or “Create” privileges on that folder or any of its subfolders AND the accounts are members of myCustomReaders by “two or more ways”,
as explained above.
Versions and patches levels experiencing this behavior:
2.3.0-a110-u47-w13-p24-20191025
2.4.0-a96-u57-w11-p12-20200324-rc1
Version and patch level not experiencing this behavior:
2.3.0 API on patch #110 and UI on patch # 45
Unfortunately, we don’t have a way to test if this is also an issue in 2.5
This issue is currently keeping us from upgrading our production instances to 2.4 and shortly after to 2.5 . We realize that code development/bug fixes may have stopped for 2.3 and 2.4, but is there another better
way to implement a global readers setup?
Thanks,
- Marwan
- [grouper-users] Global readers on folders unable to create groups, Marwan Shaher, 09/15/2020
- <Possible follow-up(s)>
- Re: [grouper-users] Global readers on folders unable to create groups, Shilen Patel, 09/16/2020
Archive powered by MHonArc 2.6.19.