Skip to Content.
Sympa Menu

grouper-dev - [grouper-dev] Attributes and permissions around them....

Subject: Grouper Developers Forum

List archive

[grouper-dev] Attributes and permissions around them....

Chronological Thread 
  • From: "Black, Carey M." <>
  • To: "" <>
  • Subject: [grouper-dev] Attributes and permissions around them....
  • Date: Fri, 10 May 2019 18:59:53 +0000

Ultimately I think I found a bug. However, I suspect some will call this a
As will all things attributes. Language makes it difficult to follow. So I
will do my best to setup the conditions. (and here are more than a few.)


2 Attribute Definitions.
Each with a single(could have more) Attribute Name.
Each with slightly different permissions.
3 groups:
A) Wheel (or some other "elevated" priv level)
B) "usersOfSystemX"
C) "groupWithAttributes_attached_to_It"

AttrDef #1:
Name = attachedToGroup ( type = Attr ), Assignable to Groups, ( multi
assigned, but I don't think this matters), Values are "String".
Has an Attribute name called "attached".
Group A: Admin
Group B : Def Read, Def Update, Attribute Read

AttrDef #2:
Name = metaDataOnGroupAssignment ( type = Attr ), Assignable to
attribute assignments on Groups, ( single assigned, but I don't think this
matters), Values are "String".
Has an Attribute name called "meta1".
Group A : Admin
Group B : Def Read, Attribute Read

User from Group A adds attributes onto group
"groupWithAttributes_attached_to_It" as follows:

Assign "attached" to the group
Add a value of "Group B can edit this string" to "attached" "
Assign "meta1" to the assignment of "attached"
Add a value for "meta1" = "A Value to show a user, but not
let them change. It drives business logic in Hooks/Change Log Consumers".
Group A : Admin
Group B can Read, Update, Attr Read, Attr Update this group.

When a user of Group B views "Attribute Assignments" for they group they see
both assignments and the values. (So far, all good.)
If the user tries to change the value of "meta1" ( Any of the Actions
menu options) the UI gives the user a screen, then fails on Submit, or delete
attempt, or update attempt. ( Again.. all good. But it would be a nice
enhancement if they could not see the Actions button in this case. :) )
The user can remove the value of "attached", add a new one, and update an
existing value. ( Still all good.)

Here is where things go sideways. ( IMHO )
If the user deletes the assignment of "attached" the UI does
something very odd.
It successfully deletes the "meta1" attribute assignment for
the user. (But they can not edit/update/delete it directly themselves! )
Then it deletes the "attached" attribute assignment too. (
Ok, they can likely do that part. )
I find two parts of this odd;
The user said "Delete the attached attribute" but the "meta1" is
deleted for them first.
Given that Grouper does not like to delete objects with
"child objects" I guess the order makes some sense.
However, the privilege escalation is a bug. ( IMHO )
And I was not able to see an "attributeAssignmentPreDelete()"
for "attached" before the delete of "meta1" started. So I could not hook the
action the user took. ( Grumble...)

Two: I have not found a permission combination that allows a user to
edit an attribute assigned to an attribute assignment without also having
edit on the attribute attached to the grouper object.
AKA: Can edit meta1, but not edit "attached".
Technically not something I want right now, but it seems like
it should be possible to do that too. I am ok if this is a design choice. It
is just not documented anywhere that I can find.

FWIW: After enough experimentation, I have a custom
AttributeAssignHooks.attributeAssignPreDelete() that will validate that the
logged in user has Admin or Update on the AttrDef of the attribute assignment
being deleted, or throws.
So I have a stop gap for the current behavior of the system.
I would rather the system change to honor the permissions of the meta
assignments consistently.

I model this on the GrouperDemo server 2.3


(And I suspect you can get Wheel on your own. :) )

Carey Matthew

Archive powered by MHonArc 2.6.19.

Top of Page