Skip to Content.
Sympa Menu

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

Subject: Grouper Developers Forum

List archive

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

Chronological Thread 
  • From: "Black, Carey M." <>
  • To: "Hyzer, Chris" <>, "" <>
  • Subject: RE: [grouper-dev] Attributes and permissions around them....
  • Date: Tue, 14 May 2019 15:02:17 +0000


I understand your view. But I think there is a clearer way to express my view

In the case of Attribute vs meta assigned Attributes:
There is a "Delete button" for the meta assignment that does not let
the user delete the meta assignment. ( So apparently there is a security
boundary that says "no delete for you".)
However, if the user "deletes" the attribute under the assignment,
then they effectively can push a (different) delete button and the privileges
that prevented them from deleting the meta data assignment is "ignored".
So the second "Delete button" violates the configured
privileges designed to protect the meta data. And meta data (Stirngs, ints,
etc...) are destroyed as a result.

It is mostly about the lost of data that really is the concern here.

In your group privileges case:
When a Subject no longer exists, (A global state change) then it (the
non-exiting subject) having privileges on any other object is irrelevant to
the other object. Even if the privilege was retained, it would not be
actionable by a non-existent subject.
I don't see that as a "destruction of data" type condition. More like
an "Elvis has left the building. So there are pointers at Elvis that are
"safe" to clean up. (After Audit logs. :) )"
And yes, if Elvis returns, those pointers would need to be recreated.
(Not auto restored. Because I would expect that Elvis Ver=2 would have a
different UUID anyways. )

Which is a very "thermo nuclear" end of life event for the object in

I think a more analogues example ( with respect to groups ) would be a
variation on your example below.
Instead of the group being deleted.
The group is given a second button ( Maybe on their own
group) that allows them to remove their privileges from the other group that
they do not have Admin privileges on. ( Think "Opt out", but for a group's
Admins to use.)
That would be an example of a "second button" that violates
some other configured privileges.
An configured condition of: "You have access, and
you're going to 'like it' ".

New... related idea....
However your example does lead to a different "feature idea". :) "Admin
notifications of important changes"
Maybe when "a subject no longer exists and a privilege is removed"
then the Admins of the affected objects (groups, attrDefs,folders) should be
told that "Elvis has left the building". They may have "new work" to start to
find a new Elvis, or not. That would be hard for the system to decide, but
easy to notify under those conditions. ( And hard for the Admins to "see"
after the fact too. )

Carey Matthew

-----Original Message-----
From: Hyzer, Chris <>
Sent: Tuesday, May 14, 2019 9:29 AM
To: Black, Carey M. <>;
Subject: RE: Attributes and permissions around them....

Lets say you create a group. And you grant privs to let other people READ
it. and someone else assigns a priv to that group to their group so your
group can UPDATE their group. But you don't have ADMIN on that other group.
Are you allowed to delete your group? In my view yes since you own it and if
someone else uses it, they are at the ADMIN of the group's mercy since the
ADMIN owns it. In your view, maybe not, since you cant unassign that
privilege assigned to your group. You would have to go around and ask
everyone to remove the references to it or maybe beg a grouper admin to
delete it...

-----Original Message-----
From: Black, Carey M. <>
Sent: Saturday, May 11, 2019 11:03 PM
To: Hyzer, Chris <>;
Subject: RE: Attributes and permissions around them....


You summarized the point better than I could. Thank you.

I think that systems should not contradict themselves.
So I hold to: "I would rather the system change to honor the
permissions of the meta assignments consistently."
I have my preference for which "consistency" I want the
system to go with. But any consistency is better than inconsistency.

RE: "I think generally if you can unassign an attribute you have some
ownership on the metadata even if you configure privileges contrary to how we
normally do (equal privs on attrs and metadata). "

If privileges are configured, then they should be honored. ( <-- This point
should win the day for the "current state is a bug" camp. )
If configured privileges are "ignored" because the system thinks they
are an "error" ( or an annoyance to a user ) then they should not be
configurable. Or at the very least, Well known to be "ignored, some of the
If privileges are "implied" ( by system design/will ) then the system
behavior should be consistent in all cases. <-- ( the system is not doing
that now.)
AKA: If all meta data privileges are driven from the
attributes they are assigned to, then the system should know that and allow
the "implied" actions under all "action" contexts.
So if the user can "delete" they should be allowed to delete
it ( the meta data) with the "delete" button on the meta data too. ( The
system is not doing that now. And I think correctly so, because I configured
the privileges to not allow it. See point one.)

Sounds like the behavior that I expected the system to enforce is not a
design of the system. ??!??

Maybe this design of the system needs:
better documentation
more consistent UI functionality to support/communicate the design

Or reconsidered?

I guess I need to plan on my current approach breaking, and come up with a
"better idea".... (Some way to "auto fix it" when the user "breaks it".
Though I think my hook should be able to essentially requiring the
meta data attributes permissions to be honored. ( Even if the "delete" button
is enabled in the UI....)
Maybe both approaches can have their our cake and eat it too?

Carey Matthew

-----Original Message-----
From: Hyzer, Chris <>
Sent: Saturday, May 11, 2019 12:32 PM
To: Black, Carey M. <>;
Subject: RE: Attributes and permissions around them....

Its very annoying not to be able to delete things. If you can remove an
attribute assignment, and don't have access to remove the metadata, it should
just do it (as it does). I think generally if you can unassign an attribute
you have some ownership on the metadata even if you configure privileges
contrary to how we normally do (equal privs on attrs and metadata). Right?

Was there something else? It's a little confusing...


-----Original Message-----
From: <>
On Behalf Of Black, Carey M.
Sent: Friday, May 10, 2019 3:00 PM
Subject: [grouper-dev] Attributes and permissions around them....

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