A conundrum: How can we allow non-admin users to create roles for users they manage?
It seems like a user may not grant other users privileges that exceed their own. Any ideas how to implement this?
Perhaps they may clone their own roles and add further search clauses, but have a readonly portion of the search clause that is AND'ed with whatever they add.
Or perhaps new roles get AND'ed with the original author's current priveleges when checking? User 'admin' creates 'ACME admin' who in turn creates 'bob'. Bob would have roles assigned by 'ACME admin' but the User.authorized(:view_users) would really be three calls:
–
“The leader must aim high, see big, judge widely, thus setting himself apart form the ordinary people who debate in narrow confines.” ~ Charles De Gaulle
“Leadership is about making others better as a result of your presence and making sure that impact lasts in your absence.” ~ Harvard Business School
I think we shouldn't do the evaluation during checking. If 'ACME admin's
privileges changed, Bob's privileges would be changed with no-one noticing it.
Why not just allow semi-admins creating a roles with permissions they are
granted? Later if they lose some privilege, it should not affect any role
they've created.
Therefore search condition should be composed during creating a new filter (if
any filter has search condition). Or we could allow user to use any search
condition (much easier for user to construct and verify) and we could check
whether the resulting set of resources is a subclass of semi-admin's granted
resources as a validation.
Comments? Other ideas?
···
--
Marek
On Saturday 13 of September 2014 18:21:16 Tom McKay wrote:
A conundrum: How can we allow non-admin users to create roles for users they
manage?
It seems like a user may not grant other users privileges that exceed their
own. Any ideas how to implement this?
Perhaps they may clone their own roles and add further search clauses, but
have a readonly portion of the search clause that is AND’ed with whatever
they add.
Or perhaps new roles get AND’ed with the original author’s current
priveleges when checking? User ‘admin’ creates ‘ACME admin’ who in turn
creates ‘bob’. Bob would have roles assigned by ‘ACME admin’ but the
User.authorized(:view_users) would really be three calls:
···
On Saturday, September 13, 2014 6:21:18 PM UTC-4, Tom McKay wrote:
>
>
> A conundrum: How can we allow non-admin users to create roles for users
> they manage?
>
> It seems like a user may not grant other users privileges that exceed
> their own. Any ideas how to implement this?
>
> Perhaps they may clone their own roles and add further search clauses, but
> have a readonly portion of the search clause that is AND'ed with whatever
> they add.
>
> Or perhaps new roles get AND'ed with the original author's current
> priveleges when checking? User 'admin' creates 'ACME admin' who in turn
> creates 'bob'. Bob would have roles assigned by 'ACME admin' but the
> User.authorized(:view_users) would really be three calls:
>
> admin.authorized(:view_users) - !admin_acme.authorized(:view_users) -
> !bob.authorized(:view_users)
>
> Any other clever ideas?
>
> --
> @thomasmckay
>
> --
> "The leader must aim high, see big, judge widely, thus setting himself
> apart form the ordinary people who debate in narrow confines." ~ Charles De
> Gaulle
>
> "Leadership is about making others better as a result of your presence and
> making sure that impact lasts in your absence." ~ Harvard Business School
>
admin gives ACME "view_hosts w/ domain=lab1.acme.com in organization ACME"
admin gives ACME "view_hosts w/ domain=lab2.acme.com in organization ACME"
ACME gives Bob "view_hosts"
Bob now has two sets of permissions, a read-only set of permissions inherited from ACME, and another set assigned directly. For every call to Host.authorized(:view_users) first the read-only permissions are called to retrieve IDs, then then assigned permission results are XOR'ed with the resulting set being what Bob can see (all hosts in domains lab1 and lab2). Does that make sense, and it is feasible to code up?
Assume Bob has priveleges to edit_users and edit_roles, when they view themselves they would see three permissions, two of them being read-only?
···
----- Original Message -----
> Hello,
>
> I think we shouldn't do the evaluation during checking. If 'ACME admin's
> privileges changed, Bob's privileges would be changed with no-one noticing
> it.
> Why not just allow semi-admins creating a roles with permissions they are
> granted? Later if they lose some privilege, it should not affect any role
> they've created.
>
> Therefore search condition should be composed during creating a new filter
> (if
> any filter has search condition). Or we could allow user to use any search
> condition (much easier for user to construct and verify) and we could check
> whether the resulting set of resources is a subclass of semi-admin's granted
> resources as a validation.
>
> Comments? Other ideas?
>
> --
> Marek
>
> On Saturday 13 of September 2014 18:21:16 Tom McKay wrote:
> > A conundrum: How can we allow non-admin users to create roles for users
> > they
> > manage?
> >
> > It seems like a user may not grant other users privileges that exceed their
> > own. Any ideas how to implement this?
> >
> > Perhaps they may clone their own roles and add further search clauses, but
> > have a readonly portion of the search clause that is AND'ed with whatever
> > they add.
> >
> > Or perhaps new roles get AND'ed with the original author's current
> > priveleges when checking? User 'admin' creates 'ACME admin' who in turn
> > creates 'bob'. Bob would have roles assigned by 'ACME admin' but the
> > User.authorized(:view_users) would really be three calls:
> >
> > admin.authorized(:view_users) - !admin_acme.authorized(:view_users) -
> > !bob.authorized(:view_users)
> >
> > Any other clever ideas?
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> admin gives ACME "view_hosts w/ domain=lab1.acme.com in organization ACME"
> admin gives ACME "view_hosts w/ domain=lab2.acme.com in organization ACME"
> ACME gives Bob "view_hosts"
>
> Bob now has two sets of permissions, a read-only set of permissions inherited
> from ACME, and another set assigned directly. For every call to
> Host.authorized(:view_users) first the read-only permissions are called to
> retrieve IDs, then then assigned permission results are XOR'ed with the
Sorry, not XOR'ed that would be bad. AND'ed
···
----- Original Message -----
resulting set being what Bob can see (all hosts in domains lab1 and lab2).
Does that make sense, and it is feasible to code up?
Assume Bob has priveleges to edit_users and edit_roles, when they view
themselves they would see three permissions, two of them being read-only?
----- Original Message -----
Hello,
I think we shouldn’t do the evaluation during checking. If 'ACME admin’s
privileges changed, Bob’s privileges would be changed with no-one noticing
it.
Why not just allow semi-admins creating a roles with permissions they are
granted? Later if they lose some privilege, it should not affect any role
they’ve created.
Therefore search condition should be composed during creating a new filter
(if
any filter has search condition). Or we could allow user to use any search
condition (much easier for user to construct and verify) and we could check
whether the resulting set of resources is a subclass of semi-admin’s
granted
resources as a validation.
Comments? Other ideas?
–
Marek
On Saturday 13 of September 2014 18:21:16 Tom McKay wrote:
A conundrum: How can we allow non-admin users to create roles for users
they
manage?
It seems like a user may not grant other users privileges that exceed
their
own. Any ideas how to implement this?
Perhaps they may clone their own roles and add further search clauses,
but
have a readonly portion of the search clause that is AND’ed with whatever
they add.
Or perhaps new roles get AND’ed with the original author’s current
priveleges when checking? User ‘admin’ creates ‘ACME admin’ who in turn
creates ‘bob’. Bob would have roles assigned by ‘ACME admin’ but the
User.authorized(:view_users) would really be three calls:
my point was that in this scenario when another assignment like this appears:
4 admin gives ACME "view_hosts w/ domain=lab3.acme.com in organization ACME"
then Bob would be granted view_hosts to lab3 as well. That does not seem to be
right to me. Definitely something that will not be clear for admin. We should
rather compute the resulting filter in step 3, so we'd do something like
3 ACME gives Bob "view_hosts w/ domain_id IN (1,2)"
where id 1 is lab1 and 2 is lab2. The computation should be intersect of ACME
user input and user current permissions and if user input is a subset of the
later we shouldn't even modify the search filter.
···
--
Marek
On Monday 15 of September 2014 14:43:58 Tom McKay wrote:
1 > admin gives ACME "view_hosts w/ domain=lab1.acme.com in organization ACME"
2 > admin gives ACME "view_hosts w/ domain=lab2.acme.com in organization ACME"
3 > ACME gives Bob “view_hosts”
Bob now has two sets of permissions, a read-only set of permissions
inherited from ACME, and another set assigned directly. For every call to
Host.authorized(:view_users) first the read-only permissions are called to
retrieve IDs, then then assigned permission results are XOR’ed with the
resulting set being what Bob can see (all hosts in domains lab1 and lab2).
Does that make sense, and it is feasible to code up?
Assume Bob has priveleges to edit_users and edit_roles, when they view
themselves they would see three permissions, two of them being read-only?
----- Original Message -----
Hello,
I think we shouldn’t do the evaluation during checking. If 'ACME admin’s
privileges changed, Bob’s privileges would be changed with no-one noticing
it.
Why not just allow semi-admins creating a roles with permissions they are
granted? Later if they lose some privilege, it should not affect any role
they’ve created.
Therefore search condition should be composed during creating a new filter
(if
any filter has search condition). Or we could allow user to use any search
condition (much easier for user to construct and verify) and we could
check
whether the resulting set of resources is a subclass of semi-admin’s
granted resources as a validation.
Comments? Other ideas?
–
Marek
On Saturday 13 of September 2014 18:21:16 Tom McKay wrote:
A conundrum: How can we allow non-admin users to create roles for users
they
manage?
It seems like a user may not grant other users privileges that exceed
their
own. Any ideas how to implement this?
Perhaps they may clone their own roles and add further search clauses,
but
have a readonly portion of the search clause that is AND’ed with
whatever
they add.
Or perhaps new roles get AND’ed with the original author’s current
priveleges when checking? User ‘admin’ creates ‘ACME admin’ who in turn
creates ‘bob’. Bob would have roles assigned by ‘ACME admin’ but the
User.authorized(:view_users) would really be three calls:
admin.authorized(:view_users) - !admin_acme.authorized(:view_users) -
Don't think my reply ever went through but I'd like to proceed with this design.
@marek, what do you think of this?
When a filter[1] is created for a resource type, the creating user's filters for that same resource type are cloned and associated to the new filter[2]. The clone is there to allow the creating user's permissions to be edited later without impacting filters they created.
When checking for access to objects, the roles for that resource must first check these linked filters first to see if the id is in the list. If it is, then the role's permissions can be checked.
In what situations should these filters be displayed to the user? Just display them to the admin?
Should there be a mechanism to "refresh" roles based on a user? This would let the user's permissions to be changed and then propagated to other roles.
···
----- Original Message -----
> I agree completely, creating user perms should be applied to new permission
> as a copy, not a reference. Saving who created the permission for use in
> ways later also seems good.
>
> Do we have enough insight to draw up a design doc? I'd like to participate
> but having @marek sign off is required, imo.
>
> Thanks!
>
> @thomasmckay
>
> > On Sep 16, 2014, at 3:40 AM, Marek Hulan wrote:
> >
> > Hi,
> >
> > my point was that in this scenario when another assignment like this
> > appears:
> > 4 admin gives ACME "view_hosts w/ domain=lab3.acme.com in organization
> > ACME"
> >
> > then Bob would be granted view_hosts to lab3 as well. That does not seem to
> > be
> > right to me. Definitely something that will not be clear for admin. We
> > should
> > rather compute the resulting filter in step 3, so we'd do something like
> >
> > 3 ACME gives Bob "view_hosts w/ domain_id IN (1,2)"
> >
> > where id 1 is lab1 and 2 is lab2. The computation should be intersect of
> > ACME
> > user input and user current permissions and if user input is a subset of
> > the
> > later we shouldn't even modify the search filter.
> >
> > --
> > Marek
> >
> > On Monday 15 of September 2014 14:43:58 Tom McKay wrote:
> > 1 > admin gives ACME "view_hosts w/ domain=lab1.acme.com in organization
> > ACME"
> > 2 > admin gives ACME "view_hosts w/ domain=lab2.acme.com in organization
> > ACME"
> > 3 > ACME gives Bob "view_hosts"
> >
> >> Bob now has two sets of permissions, a read-only set of permissions
> >> inherited from ACME, and another set assigned directly. For every call to
> >> Host.authorized(:view_users) first the read-only permissions are called to
> >> retrieve IDs, then then assigned permission results are XOR'ed with the
> >> resulting set being what Bob can see (all hosts in domains lab1 and lab2).
> >> Does that make sense, and it is feasible to code up?
> >>
> >> Assume Bob has priveleges to edit_users and edit_roles, when they view
> >> themselves they would see three permissions, two of them being read-only?
> >>
> >> ----- Original Message -----
> >>
> >>> Hello,
> >>>
> >>> I think we shouldn't do the evaluation during checking. If 'ACME admin's
> >>> privileges changed, Bob's privileges would be changed with no-one
> >>> noticing
> >>> it.
> >>> Why not just allow semi-admins creating a roles with permissions they are
> >>> granted? Later if they lose some privilege, it should not affect any role
> >>> they've created.
> >>>
> >>> Therefore search condition should be composed during creating a new
> >>> filter
> >>> (if
> >>> any filter has search condition). Or we could allow user to use any
> >>> search
> >>> condition (much easier for user to construct and verify) and we could
> >>> check
> >>> whether the resulting set of resources is a subclass of semi-admin's
> >>> granted resources as a validation.
> >>>
> >>> Comments? Other ideas?
> >>>
> >>> --
> >>> Marek
> >>>
> >>>> On Saturday 13 of September 2014 18:21:16 Tom McKay wrote:
> >>>> A conundrum: How can we allow non-admin users to create roles for users
> >>>> they
> >>>> manage?
> >>>>
> >>>> It seems like a user may not grant other users privileges that exceed
> >>>> their
> >>>> own. Any ideas how to implement this?
> >>>>
> >>>> Perhaps they may clone their own roles and add further search clauses,
> >>>> but
> >>>> have a readonly portion of the search clause that is AND'ed with
> >>>> whatever
> >>>> they add.
> >>>>
> >>>> Or perhaps new roles get AND'ed with the original author's current
> >>>> priveleges when checking? User 'admin' creates 'ACME admin' who in turn
> >>>> creates 'bob'. Bob would have roles assigned by 'ACME admin' but the
> >>>>
> >>>> User.authorized(:view_users) would really be three calls:
> >>>> admin.authorized(:view_users) - !admin_acme.authorized(:view_users) -
> >>>>
> >>>> !bob.authorized(:view_users)
> >>>>
> >>>> Any other clever ideas?
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "foreman-dev" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send an
> >>> email to foreman-dev+unsubscribe@googlegroups.com.
> >>> For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > Marek
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "foreman-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to foreman-dev+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
note that the cloning is not enough. We must make sure that changing search
condition does not result in allowing access to more resources. This won't be
trivial and the result can change in time.
Maybe I should have asked in first reply, but… do we need such advanced
delegation? Is it too limiting to have only admins that can configure roles for
users and usergroups? Or have one permission allowing to configure arbitrary
permissions (= admin in fact)? Delegation makes sense (and should already
work) per organization and per location, do we need to support delegation of
permission subset in particular org or loc? I think that authorization should
be as easy as possible so users always understand the result. When we start
with this delegation it starts to be complicated.
Ad refresh - I think what you've described is basically masked as a role that
wraps specific filters configuration. So refresh should not be needed if we have
permissions modeled by roles properly?
This clearly deserves more attention. I'd like to hear opinions from others
before diving into big design.
···
--
Marek
On Monday 22 of September 2014 14:34:29 Tom McKay wrote:
Don’t think my reply ever went through but I’d like to proceed with this
design.
@marek, what do you think of this?
When a filter[1] is created for a resource type, the creating user’s filters
for that same resource type are cloned and associated to the new filter[2].
The clone is there to allow the creating user’s permissions to be edited
later without impacting filters they created. When checking for access to
objects, the roles for that resource must first check these linked filters
first to see if the id is in the list. If it is, then the role’s
permissions can be checked.
In what situations should these filters be displayed to the user? Just
display them to the admin? Should there be a mechanism to “refresh” roles
based on a user? This would let the user’s permissions to be changed and
then propagated to other roles.
I agree completely, creating user perms should be applied to new
permission
as a copy, not a reference. Saving who created the permission for use in
ways later also seems good.
Do we have enough insight to draw up a design doc? I’d like to participate
but having @marek sign off is required, imo.
my point was that in this scenario when another assignment like this
appears:
4 admin gives ACME “view_hosts w/ domain=lab3.acme.com in organization
ACME”
then Bob would be granted view_hosts to lab3 as well. That does not seem
to
be
right to me. Definitely something that will not be clear for admin. We
should
rather compute the resulting filter in step 3, so we’d do something like
3 ACME gives Bob “view_hosts w/ domain_id IN (1,2)”
where id 1 is lab1 and 2 is lab2. The computation should be intersect of
ACME
user input and user current permissions and if user input is a subset of
the
later we shouldn’t even modify the search filter.
–
Marek
On Monday 15 of September 2014 14:43:58 Tom McKay wrote:
1 > admin gives ACME "view_hosts w/ domain=lab1.acme.com in organization
ACME"
2 > admin gives ACME "view_hosts w/ domain=lab2.acme.com in organization
ACME"
3 > ACME gives Bob “view_hosts”
Bob now has two sets of permissions, a read-only set of permissions
inherited from ACME, and another set assigned directly. For every call
to
Host.authorized(:view_users) first the read-only permissions are called
to
retrieve IDs, then then assigned permission results are XOR’ed with the
resulting set being what Bob can see (all hosts in domains lab1 and
lab2).
Does that make sense, and it is feasible to code up?
Assume Bob has priveleges to edit_users and edit_roles, when they view
themselves they would see three permissions, two of them being
read-only?
----- Original Message -----
Hello,
I think we shouldn’t do the evaluation during checking. If 'ACME
admin’s
privileges changed, Bob’s privileges would be changed with no-one
noticing
it.
Why not just allow semi-admins creating a roles with permissions they
are
granted? Later if they lose some privilege, it should not affect any
role
they’ve created.
Therefore search condition should be composed during creating a new
filter
(if
any filter has search condition). Or we could allow user to use any
search
condition (much easier for user to construct and verify) and we could
check
whether the resulting set of resources is a subclass of semi-admin’s
granted resources as a validation.
Comments? Other ideas?
–
Marek
On Saturday 13 of September 2014 18:21:16 Tom McKay wrote:
A conundrum: How can we allow non-admin users to create roles for
users
they
manage?
It seems like a user may not grant other users privileges that exceed
their
own. Any ideas how to implement this?
Perhaps they may clone their own roles and add further search
clauses,
but
have a readonly portion of the search clause that is AND’ed with
whatever
they add.
Or perhaps new roles get AND’ed with the original author’s current
priveleges when checking? User ‘admin’ creates ‘ACME admin’ who in
turn
creates ‘bob’. Bob would have roles assigned by ‘ACME admin’ but the
User.authorized(:view_users) would really be three calls:
admin.authorized(:view_users) - !admin_acme.authorized(:view_users)
My point of view is that there should be very little that requires a user with full admin privileges to do when it comes to normal usage of foreman and katello. (For example, I am against the "fix mismatches" functionality requiring an admin.) I'd expect that an organization admin would be more common, or a location admin. These power users would need to have their abilities to create sub-roles in a fashion that did not exceed their own permissions.
More notes inline…
> Hello,
>
> note that the cloning is not enough. We must make sure that changing search
> condition does not result in allowing access to more resources. This won't be
> trivial and the result can change in time.
Right, I'd expect that a "deep clone" would be necessary so that the cloned filters are stable even if the original source changed.
>
> Maybe I should have asked in first reply, but… do we need such advanced
> delegation? Is it too limiting to have only admins that can configure roles
> for
> users and usergroups? Or have one permission allowing to configure arbitrary
> permissions (= admin in fact)? Delegation makes sense (and should already
> work) per organization and per location, do we need to support delegation of
> permission subset in particular org or loc? I think that authorization should
> be as easy as possible so users always understand the result. When we start
> with this delegation it starts to be complicated.
>
> Ad refresh - I think what you've described is basically masked as a role that
> wraps specific filters configuration. So refresh should not be needed if we
> have
> permissions modeled by roles properly?
>
> This clearly deserves more attention. I'd like to hear opinions from others
> before diving into big design.
Usually conversations don't get stirred up until something workable is demo'ed. I'll work on something this week as a proof of concept.
···
----- Original Message -----
–
Marek
On Monday 22 of September 2014 14:34:29 Tom McKay wrote:
Don’t think my reply ever went through but I’d like to proceed with this
design.
@marek, what do you think of this?
When a filter[1] is created for a resource type, the creating user’s
filters
for that same resource type are cloned and associated to the new filter[2].
The clone is there to allow the creating user’s permissions to be edited
later without impacting filters they created. When checking for access to
objects, the roles for that resource must first check these linked filters
first to see if the id is in the list. If it is, then the role’s
permissions can be checked.
In what situations should these filters be displayed to the user? Just
display them to the admin? Should there be a mechanism to “refresh” roles
based on a user? This would let the user’s permissions to be changed and
then propagated to other roles.
I agree completely, creating user perms should be applied to new
permission
as a copy, not a reference. Saving who created the permission for use in
ways later also seems good.
Do we have enough insight to draw up a design doc? I’d like to
participate
but having @marek sign off is required, imo.
my point was that in this scenario when another assignment like this
appears:
4 admin gives ACME “view_hosts w/ domain=lab3.acme.com in organization
ACME”
then Bob would be granted view_hosts to lab3 as well. That does not
seem
to
be
right to me. Definitely something that will not be clear for admin. We
should
rather compute the resulting filter in step 3, so we’d do something
like
3 ACME gives Bob “view_hosts w/ domain_id IN (1,2)”
where id 1 is lab1 and 2 is lab2. The computation should be intersect
of
ACME
user input and user current permissions and if user input is a subset
of
the
later we shouldn’t even modify the search filter.
–
Marek
On Monday 15 of September 2014 14:43:58 Tom McKay wrote:
1 > admin gives ACME "view_hosts w/ domain=lab1.acme.com in
organization
ACME"
2 > admin gives ACME "view_hosts w/ domain=lab2.acme.com in
organization
ACME"
3 > ACME gives Bob “view_hosts”
Bob now has two sets of permissions, a read-only set of permissions
inherited from ACME, and another set assigned directly. For every call
to
Host.authorized(:view_users) first the read-only permissions are
called
to
retrieve IDs, then then assigned permission results are XOR’ed with
the
resulting set being what Bob can see (all hosts in domains lab1 and
lab2).
Does that make sense, and it is feasible to code up?
Assume Bob has priveleges to edit_users and edit_roles, when they view
themselves they would see three permissions, two of them being
read-only?
----- Original Message -----
Hello,
I think we shouldn’t do the evaluation during checking. If 'ACME
admin’s
privileges changed, Bob’s privileges would be changed with no-one
noticing
it.
Why not just allow semi-admins creating a roles with permissions they
are
granted? Later if they lose some privilege, it should not affect any
role
they’ve created.
Therefore search condition should be composed during creating a new
filter
(if
any filter has search condition). Or we could allow user to use any
search
condition (much easier for user to construct and verify) and we could
check
whether the resulting set of resources is a subclass of semi-admin’s
granted resources as a validation.
Comments? Other ideas?
–
Marek
On Saturday 13 of September 2014 18:21:16 Tom McKay wrote:
A conundrum: How can we allow non-admin users to create roles for
users
they
manage?
It seems like a user may not grant other users privileges that
exceed
their
own. Any ideas how to implement this?
Perhaps they may clone their own roles and add further search
clauses,
but
have a readonly portion of the search clause that is AND’ed with
whatever
they add.
Or perhaps new roles get AND’ed with the original author’s current
priveleges when checking? User ‘admin’ creates ‘ACME admin’ who in
turn
creates ‘bob’. Bob would have roles assigned by ‘ACME admin’ but the
User.authorized(:view_users) would really be three calls:
admin.authorized(:view_users) - !admin_acme.authorized(:view_users)
@mhulan - Can you give me some guidance on where in the code I could pre-apply some filters to reduce the data set?
User ONE with role/filter "ConfigTemplate/view_templates/name~Katello". This user in turn creates a role/filter "ConfigTemplate/view_templates/Unlimited". This filter gets ONE's own filter associated to it.
User TWO is assigned the unlimited role ONE created. TWO should see only the templates that ONE could see, the Katello named ones. Where in the authorize code could I perform this? ConfigTemplate.where(ONE.authorized) & ConfigTemplate.where(TWO.authorized)
···
----- Original Message -----
>
> My point of view is that there should be very little that requires a user
> with full admin privileges to do when it comes to normal usage of foreman
> and katello. (For example, I am against the "fix mismatches" functionality
> requiring an admin.) I'd expect that an organization admin would be more
> common, or a location admin. These power users would need to have their
> abilities to create sub-roles in a fashion that did not exceed their own
> permissions.
>
> More notes inline...
>
> ----- Original Message -----
> > Hello,
> >
> > note that the cloning is not enough. We must make sure that changing search
> > condition does not result in allowing access to more resources. This won't
> > be
> > trivial and the result can change in time.
>
> Right, I'd expect that a "deep clone" would be necessary so that the cloned
> filters are stable even if the original source changed.
>
> >
> > Maybe I should have asked in first reply, but... do we need such advanced
> > delegation? Is it too limiting to have only admins that can configure roles
> > for
> > users and usergroups? Or have one permission allowing to configure
> > arbitrary
> > permissions (= admin in fact)? Delegation makes sense (and should already
> > work) per organization and per location, do we need to support delegation
> > of
> > permission subset in particular org or loc? I think that authorization
> > should
> > be as easy as possible so users always understand the result. When we start
> > with this delegation it starts to be complicated.
> >
> > Ad refresh - I think what you've described is basically masked as a role
> > that
> > wraps specific filters configuration. So refresh should not be needed if we
> > have
> > permissions modeled by roles properly?
> >
> > This clearly deserves more attention. I'd like to hear opinions from others
> > before diving into big design.
>
> Usually conversations don't get stirred up until something workable is
> demo'ed. I'll work on something this week as a proof of concept.
>
> >
> > --
> > Marek
> >
> > On Monday 22 of September 2014 14:34:29 Tom McKay wrote:
> > > Don't think my reply ever went through but I'd like to proceed with this
> > > design.
> > >
> > > @marek, what do you think of this?
> > >
> > > When a filter[1] is created for a resource type, the creating user's
> > > filters
> > > for that same resource type are cloned and associated to the new
> > > filter[2].
> > > The clone is there to allow the creating user's permissions to be edited
> > > later without impacting filters they created. When checking for access to
> > > objects, the roles for that resource must first check these linked
> > > filters
> > > first to see if the id is in the list. If it is, then the role's
> > > permissions can be checked.
> > >
> > > In what situations should these filters be displayed to the user? Just
> > > display them to the admin? Should there be a mechanism to "refresh" roles
> > > based on a user? This would let the user's permissions to be changed and
> > > then propagated to other roles.
> > >
> > >
> > > [1]
> > > https://github.com/theforeman/foreman/blob/develop/app/models/filter.rb
> > > [2] has_many :filters, :dependent => :destroy
> > >
> > >
> > > ----- Original Message -----
> > >
> > > > I agree completely, creating user perms should be applied to new
> > > > permission
> > > > as a copy, not a reference. Saving who created the permission for use
> > > > in
> > > > ways later also seems good.
> > > >
> > > > Do we have enough insight to draw up a design doc? I'd like to
> > > > participate
> > > > but having @marek sign off is required, imo.
> > > >
> > > > Thanks!
> > > >
> > > > @thomasmckay
> > > >
> > > > > On Sep 16, 2014, at 3:40 AM, Marek Hulan wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > my point was that in this scenario when another assignment like this
> > > > > appears:
> > > > > 4 admin gives ACME "view_hosts w/ domain=lab3.acme.com in
> > > > > organization
> > > > > ACME"
> > > > >
> > > > > then Bob would be granted view_hosts to lab3 as well. That does not
> > > > > seem
> > > > > to
> > > > > be
> > > > > right to me. Definitely something that will not be clear for admin.
> > > > > We
> > > > > should
> > > > > rather compute the resulting filter in step 3, so we'd do something
> > > > > like
> > > > >
> > > > > 3 ACME gives Bob "view_hosts w/ domain_id IN (1,2)"
> > > > >
> > > > > where id 1 is lab1 and 2 is lab2. The computation should be intersect
> > > > > of
> > > > > ACME
> > > > > user input and user current permissions and if user input is a subset
> > > > > of
> > > > > the
> > > > > later we shouldn't even modify the search filter.
> > > > >
> > > > > --
> > > > > Marek
> > > > >
> > > > > On Monday 15 of September 2014 14:43:58 Tom McKay wrote:
> > > > > 1 > admin gives ACME "view_hosts w/ domain=lab1.acme.com in
> > > > > organization
> > > > > ACME"
> > > > > 2 > admin gives ACME "view_hosts w/ domain=lab2.acme.com in
> > > > > organization
> > > > > ACME"
> > > > > 3 > ACME gives Bob "view_hosts"
> > > > >
> > > > >> Bob now has two sets of permissions, a read-only set of permissions
> > > > >> inherited from ACME, and another set assigned directly. For every
> > > > >> call
> > > > >> to
> > > > >> Host.authorized(:view_users) first the read-only permissions are
> > > > >> called
> > > > >> to
> > > > >> retrieve IDs, then then assigned permission results are XOR'ed with
> > > > >> the
> > > > >> resulting set being what Bob can see (all hosts in domains lab1 and
> > > > >> lab2).
> > > > >> Does that make sense, and it is feasible to code up?
> > > > >>
> > > > >> Assume Bob has priveleges to edit_users and edit_roles, when they
> > > > >> view
> > > > >> themselves they would see three permissions, two of them being
> > > > >> read-only?
> > > > >>
> > > > >> ----- Original Message -----
> > > > >>
> > > > >>> Hello,
> > > > >>>
> > > > >>> I think we shouldn't do the evaluation during checking. If 'ACME
> > > > >>> admin's
> > > > >>> privileges changed, Bob's privileges would be changed with no-one
> > > > >>> noticing
> > > > >>> it.
> > > > >>> Why not just allow semi-admins creating a roles with permissions
> > > > >>> they
> > > > >>> are
> > > > >>> granted? Later if they lose some privilege, it should not affect
> > > > >>> any
> > > > >>> role
> > > > >>> they've created.
> > > > >>>
> > > > >>> Therefore search condition should be composed during creating a new
> > > > >>> filter
> > > > >>> (if
> > > > >>> any filter has search condition). Or we could allow user to use any
> > > > >>> search
> > > > >>> condition (much easier for user to construct and verify) and we
> > > > >>> could
> > > > >>> check
> > > > >>> whether the resulting set of resources is a subclass of
> > > > >>> semi-admin's
> > > > >>> granted resources as a validation.
> > > > >>>
> > > > >>> Comments? Other ideas?
> > > > >>>
> > > > >>> --
> > > > >>> Marek
> > > > >>>
> > > > >>>> On Saturday 13 of September 2014 18:21:16 Tom McKay wrote:
> > > > >>>> A conundrum: How can we allow non-admin users to create roles for
> > > > >>>> users
> > > > >>>> they
> > > > >>>> manage?
> > > > >>>>
> > > > >>>> It seems like a user may not grant other users privileges that
> > > > >>>> exceed
> > > > >>>> their
> > > > >>>> own. Any ideas how to implement this?
> > > > >>>>
> > > > >>>> Perhaps they may clone their own roles and add further search
> > > > >>>> clauses,
> > > > >>>> but
> > > > >>>> have a readonly portion of the search clause that is AND'ed with
> > > > >>>> whatever
> > > > >>>> they add.
> > > > >>>>
> > > > >>>> Or perhaps new roles get AND'ed with the original author's current
> > > > >>>> priveleges when checking? User 'admin' creates 'ACME admin' who in
> > > > >>>> turn
> > > > >>>> creates 'bob'. Bob would have roles assigned by 'ACME admin' but
> > > > >>>> the
> > > > >>>>
> > > > >>>> User.authorized(:view_users) would really be three calls:
> > > > >>>> admin.authorized(:view_users) -
> > > > >>>> !admin_acme.authorized(:view_users)
> > > > >>>> -
> > > > >>>>
> > > > >>>> !bob.authorized(:view_users)
> > > > >>>>
> > > > >>>> Any other clever ideas?
> > > > >>>
> > > > >>> --
> > > > >>> You received this message because you are subscribed to the Google
> > > > >>> Groups
> > > > >>> "foreman-dev" group.
> > > > >>> To unsubscribe from this group and stop receiving emails from it,
> > > > >>> send
> > > > >>> an
> > > > >>> email to foreman-dev+unsubscribe@googlegroups.com.
> > > > >>> For more options, visit https://groups.google.com/d/optout.
> > > > >
> > > > > --
> > > > > Marek
> > > > >
> > > > > --
> > > > > You received this message because you are subscribed to the Google
> > > > > Groups
> > > > > "foreman-dev" group.
> > > > > To unsubscribe from this group and stop receiving emails from it,
> > > > > send
> > > > > an
> > > > > email to foreman-dev+unsubscribe@googlegroups.com.
> > > > > For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "foreman-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to foreman-dev+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
> @mhulan - Can you give me some guidance on where in the code I could
> pre-apply some filters to reduce the data set?
For the record, I think you want to look at
> User ONE with role/filter "ConfigTemplate/view_templates/name~Katello". This
> user in turn creates a role/filter
> "ConfigTemplate/view_templates/Unlimited". This filter gets ONE's own
> filter associated to it.
As I've mentioned several times, I think we shouldn't associate filters. We
should not allow to create unlimited filer in the first place. The unlimited
filter should be restricted during save so it allows only to see templates name
~ Katello. Also note, that this may still not be correct if you think about
taxonomies.
> User TWO is assigned the unlimited role ONE created. TWO should see only the
> templates that ONE could see, the Katello named ones. Where in the
> authorize code could I perform this? ConfigTemplate.where(ONE.authorized) &
> ConfigTemplate.where(TWO.authorized)
Authorizer class (mentioned above) would be the right place I think.
···
On Tuesday 23 of September 2014 20:52:48 Tom McKay wrote:
–
Marek
----- Original Message -----
My point of view is that there should be very little that requires a user
with full admin privileges to do when it comes to normal usage of foreman
and katello. (For example, I am against the “fix mismatches” functionality
requiring an admin.) I’d expect that an organization admin would be more
common, or a location admin. These power users would need to have their
abilities to create sub-roles in a fashion that did not exceed their own
permissions.
More notes inline…
----- Original Message -----
Hello,
note that the cloning is not enough. We must make sure that changing
search
condition does not result in allowing access to more resources. This
won’t
be
trivial and the result can change in time.
Right, I’d expect that a “deep clone” would be necessary so that the
cloned
filters are stable even if the original source changed.
Maybe I should have asked in first reply, but… do we need such
advanced
delegation? Is it too limiting to have only admins that can configure
roles
for
users and usergroups? Or have one permission allowing to configure
arbitrary
permissions (= admin in fact)? Delegation makes sense (and should
already
work) per organization and per location, do we need to support
delegation
of
permission subset in particular org or loc? I think that authorization
should
be as easy as possible so users always understand the result. When we
start
with this delegation it starts to be complicated.
Ad refresh - I think what you’ve described is basically masked as a role
that
wraps specific filters configuration. So refresh should not be needed if
we
have
permissions modeled by roles properly?
This clearly deserves more attention. I’d like to hear opinions from
others
before diving into big design.
Usually conversations don’t get stirred up until something workable is
demo’ed. I’ll work on something this week as a proof of concept.
–
Marek
On Monday 22 of September 2014 14:34:29 Tom McKay wrote:
Don’t think my reply ever went through but I’d like to proceed with
this
design.
@marek, what do you think of this?
When a filter[1] is created for a resource type, the creating user’s
filters
for that same resource type are cloned and associated to the new
filter[2].
The clone is there to allow the creating user’s permissions to be
edited
later without impacting filters they created. When checking for access
to
objects, the roles for that resource must first check these linked
filters
first to see if the id is in the list. If it is, then the role’s
permissions can be checked.
In what situations should these filters be displayed to the user? Just
display them to the admin? Should there be a mechanism to "refresh"
roles
based on a user? This would let the user’s permissions to be changed
and
then propagated to other roles.
I agree completely, creating user perms should be applied to new
permission
as a copy, not a reference. Saving who created the permission for
use
in
ways later also seems good.
Do we have enough insight to draw up a design doc? I’d like to
participate
but having @marek sign off is required, imo.
On Sep 16, 2014, at 3:40 AM, Marek Hulan mhulan@redhat.com > > > > > > wrote:
Hi,
my point was that in this scenario when another assignment like
this
appears:
4 admin gives ACME “view_hosts w/ domain=lab3.acme.com in
organization
ACME”
then Bob would be granted view_hosts to lab3 as well. That does
not
seem
to
be
right to me. Definitely something that will not be clear for
admin.
We
should
rather compute the resulting filter in step 3, so we’d do
something
like
3 ACME gives Bob “view_hosts w/ domain_id IN (1,2)”
where id 1 is lab1 and 2 is lab2. The computation should be
intersect
of
ACME
user input and user current permissions and if user input is a
subset
of
the
later we shouldn’t even modify the search filter.
–
Marek
On Monday 15 of September 2014 14:43:58 Tom McKay wrote:
1 > admin gives ACME "view_hosts w/ domain=lab1.acme.com in
organization
ACME"
2 > admin gives ACME "view_hosts w/ domain=lab2.acme.com in
organization
ACME"
3 > ACME gives Bob “view_hosts”
Bob now has two sets of permissions, a read-only set of
permissions
inherited from ACME, and another set assigned directly. For every
call
to
Host.authorized(:view_users) first the read-only permissions are
called
to
retrieve IDs, then then assigned permission results are XOR’ed
with
the
resulting set being what Bob can see (all hosts in domains lab1
and
lab2).
Does that make sense, and it is feasible to code up?
Assume Bob has priveleges to edit_users and edit_roles, when they
view
themselves they would see three permissions, two of them being
read-only?
----- Original Message -----
Hello,
I think we shouldn’t do the evaluation during checking. If 'ACME
admin’s
privileges changed, Bob’s privileges would be changed with
no-one
noticing
it.
Why not just allow semi-admins creating a roles with permissions
they
are
granted? Later if they lose some privilege, it should not affect
any
role
they’ve created.
Therefore search condition should be composed during creating a
new
filter
(if
any filter has search condition). Or we could allow user to use
any
search
condition (much easier for user to construct and verify) and we
could
check
whether the resulting set of resources is a subclass of
semi-admin’s
granted resources as a validation.
Comments? Other ideas?
–
Marek
On Saturday 13 of September 2014 18:21:16 Tom McKay wrote:
A conundrum: How can we allow non-admin users to create roles
for
users
they
manage?
It seems like a user may not grant other users privileges that
exceed
their
own. Any ideas how to implement this?
Perhaps they may clone their own roles and add further search
clauses,
but
have a readonly portion of the search clause that is AND’ed
with
whatever
they add.
Or perhaps new roles get AND’ed with the original author’s
current
priveleges when checking? User ‘admin’ creates ‘ACME admin’ who
in
turn
creates ‘bob’. Bob would have roles assigned by 'ACME admin’
but
the
User.authorized(:view_users) would really be three calls:
admin.authorized(:view_users) -
!admin_acme.authorized(:view_users)
Thanks to Marek (@mhulan) for pointing me in the right direction. Here's a brief video demo of what I am proposing.
···
----- Original Message -----
> On Tuesday 23 of September 2014 20:52:48 Tom McKay wrote:
> > @mhulan - Can you give me some guidance on where in the code I could
> > pre-apply some filters to reduce the data set?
>
> For the record, I think you want to look at
> https://github.com/theforeman/foreman/blob/develop/app/services/authorizer.rb
>
> > User ONE with role/filter "ConfigTemplate/view_templates/name~Katello".
> > This
> > user in turn creates a role/filter
> > "ConfigTemplate/view_templates/Unlimited". This filter gets ONE's own
> > filter associated to it.
>
> As I've mentioned several times, I think we shouldn't associate filters. We
> should not allow to create unlimited filer in the first place. The unlimited
> filter should be restricted during save so it allows only to see templates
> name
> ~ Katello. Also note, that this may still not be correct if you think about
> taxonomies.
>
> > User TWO is assigned the unlimited role ONE created. TWO should see only
> > the
> > templates that ONE could see, the Katello named ones. Where in the
> > authorize code could I perform this? ConfigTemplate.where(ONE.authorized) &
> > ConfigTemplate.where(TWO.authorized)
>
> Authorizer class (mentioned above) would be the right place I think.
>
> --
> Marek
>
> >
> >
> >
> > ----- Original Message -----
> >
> > > My point of view is that there should be very little that requires a user
> > > with full admin privileges to do when it comes to normal usage of foreman
> > > and katello. (For example, I am against the "fix mismatches"
> > > functionality
> > > requiring an admin.) I'd expect that an organization admin would be more
> > > common, or a location admin. These power users would need to have their
> > > abilities to create sub-roles in a fashion that did not exceed their own
> > > permissions.
> > >
> > > More notes inline...
> > >
> > > ----- Original Message -----
> > >
> > > > Hello,
> > > >
> > > > note that the cloning is not enough. We must make sure that changing
> > > > search
> > > > condition does not result in allowing access to more resources. This
> > > > won't
> > > > be
> > > > trivial and the result can change in time.
> > >
> > > Right, I'd expect that a "deep clone" would be necessary so that the
> > > cloned
> > > filters are stable even if the original source changed.
> > >
> > > > Maybe I should have asked in first reply, but... do we need such
> > > > advanced
> > > > delegation? Is it too limiting to have only admins that can configure
> > > > roles
> > > > for
> > > > users and usergroups? Or have one permission allowing to configure
> > > > arbitrary
> > > > permissions (= admin in fact)? Delegation makes sense (and should
> > > > already
> > > > work) per organization and per location, do we need to support
> > > > delegation
> > > > of
> > > > permission subset in particular org or loc? I think that authorization
> > > > should
> > > > be as easy as possible so users always understand the result. When we
> > > > start
> > > > with this delegation it starts to be complicated.
> > > >
> > > > Ad refresh - I think what you've described is basically masked as a
> > > > role
> > > > that
> > > > wraps specific filters configuration. So refresh should not be needed
> > > > if
> > > > we
> > > > have
> > > > permissions modeled by roles properly?
> > > >
> > > > This clearly deserves more attention. I'd like to hear opinions from
> > > > others
> > > > before diving into big design.
> > >
> > > Usually conversations don't get stirred up until something workable is
> > > demo'ed. I'll work on something this week as a proof of concept.
> > >
> > > > --
> > > > Marek
> > > >
> > > > On Monday 22 of September 2014 14:34:29 Tom McKay wrote:
> > > > > Don't think my reply ever went through but I'd like to proceed with
> > > > > this
> > > > > design.
> > > > >
> > > > > @marek, what do you think of this?
> > > > >
> > > > > When a filter[1] is created for a resource type, the creating user's
> > > > > filters
> > > > > for that same resource type are cloned and associated to the new
> > > > > filter[2].
> > > > > The clone is there to allow the creating user's permissions to be
> > > > > edited
> > > > > later without impacting filters they created. When checking for
> > > > > access
> > > > > to
> > > > > objects, the roles for that resource must first check these linked
> > > > > filters
> > > > > first to see if the id is in the list. If it is, then the role's
> > > > > permissions can be checked.
> > > > >
> > > > > In what situations should these filters be displayed to the user?
> > > > > Just
> > > > > display them to the admin? Should there be a mechanism to "refresh"
> > > > > roles
> > > > > based on a user? This would let the user's permissions to be changed
> > > > > and
> > > > > then propagated to other roles.
> > > > >
> > > > >
> > > > > [1]
> > > > > https://github.com/theforeman/foreman/blob/develop/app/models/filter.r
> > > > > b
> > > > > [2] has_many :filters, :dependent => :destroy
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > >
> > > > > > I agree completely, creating user perms should be applied to new
> > > > > > permission
> > > > > > as a copy, not a reference. Saving who created the permission for
> > > > > > use
> > > > > > in
> > > > > > ways later also seems good.
> > > > > >
> > > > > > Do we have enough insight to draw up a design doc? I'd like to
> > > > > > participate
> > > > > > but having @marek sign off is required, imo.
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > @thomasmckay
> > > > > >
> > > > > > > On Sep 16, 2014, at 3:40 AM, Marek Hulan > > > > > > > wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > my point was that in this scenario when another assignment like
> > > > > > > this
> > > > > > > appears:
> > > > > > > 4 admin gives ACME "view_hosts w/ domain=lab3.acme.com in
> > > > > > > organization
> > > > > > > ACME"
> > > > > > >
> > > > > > > then Bob would be granted view_hosts to lab3 as well. That does
> > > > > > > not
> > > > > > > seem
> > > > > > > to
> > > > > > > be
> > > > > > > right to me. Definitely something that will not be clear for
> > > > > > > admin.
> > > > > > > We
> > > > > > > should
> > > > > > > rather compute the resulting filter in step 3, so we'd do
> > > > > > > something
> > > > > > > like
> > > > > > >
> > > > > > > 3 ACME gives Bob "view_hosts w/ domain_id IN (1,2)"
> > > > > > >
> > > > > > > where id 1 is lab1 and 2 is lab2. The computation should be
> > > > > > > intersect
> > > > > > > of
> > > > > > > ACME
> > > > > > > user input and user current permissions and if user input is a
> > > > > > > subset
> > > > > > > of
> > > > > > > the
> > > > > > > later we shouldn't even modify the search filter.
> > > > > > >
> > > > > > > --
> > > > > > > Marek
> > > > > > >
> > > > > > > On Monday 15 of September 2014 14:43:58 Tom McKay wrote:
> > > > > > > 1 > admin gives ACME "view_hosts w/ domain=lab1.acme.com in
> > > > > > > organization
> > > > > > > ACME"
> > > > > > > 2 > admin gives ACME "view_hosts w/ domain=lab2.acme.com in
> > > > > > > organization
> > > > > > > ACME"
> > > > > > > 3 > ACME gives Bob "view_hosts"
> > > > > > >
> > > > > > >> Bob now has two sets of permissions, a read-only set of
> > > > > > >> permissions
> > > > > > >> inherited from ACME, and another set assigned directly. For
> > > > > > >> every
> > > > > > >> call
> > > > > > >> to
> > > > > > >> Host.authorized(:view_users) first the read-only permissions are
> > > > > > >> called
> > > > > > >> to
> > > > > > >> retrieve IDs, then then assigned permission results are XOR'ed
> > > > > > >> with
> > > > > > >> the
> > > > > > >> resulting set being what Bob can see (all hosts in domains lab1
> > > > > > >> and
> > > > > > >> lab2).
> > > > > > >> Does that make sense, and it is feasible to code up?
> > > > > > >>
> > > > > > >> Assume Bob has priveleges to edit_users and edit_roles, when
> > > > > > >> they
> > > > > > >> view
> > > > > > >> themselves they would see three permissions, two of them being
> > > > > > >> read-only?
> > > > > > >>
> > > > > > >> ----- Original Message -----
> > > > > > >>
> > > > > > >>> Hello,
> > > > > > >>>
> > > > > > >>> I think we shouldn't do the evaluation during checking. If
> > > > > > >>> 'ACME
> > > > > > >>> admin's
> > > > > > >>> privileges changed, Bob's privileges would be changed with
> > > > > > >>> no-one
> > > > > > >>> noticing
> > > > > > >>> it.
> > > > > > >>> Why not just allow semi-admins creating a roles with
> > > > > > >>> permissions
> > > > > > >>> they
> > > > > > >>> are
> > > > > > >>> granted? Later if they lose some privilege, it should not
> > > > > > >>> affect
> > > > > > >>> any
> > > > > > >>> role
> > > > > > >>> they've created.
> > > > > > >>>
> > > > > > >>> Therefore search condition should be composed during creating a
> > > > > > >>> new
> > > > > > >>> filter
> > > > > > >>> (if
> > > > > > >>> any filter has search condition). Or we could allow user to use
> > > > > > >>> any
> > > > > > >>> search
> > > > > > >>> condition (much easier for user to construct and verify) and we
> > > > > > >>> could
> > > > > > >>> check
> > > > > > >>> whether the resulting set of resources is a subclass of
> > > > > > >>> semi-admin's
> > > > > > >>> granted resources as a validation.
> > > > > > >>>
> > > > > > >>> Comments? Other ideas?
> > > > > > >>>
> > > > > > >>> --
> > > > > > >>> Marek
> > > > > > >>>
> > > > > > >>>> On Saturday 13 of September 2014 18:21:16 Tom McKay wrote:
> > > > > > >>>> A conundrum: How can we allow non-admin users to create roles
> > > > > > >>>> for
> > > > > > >>>> users
> > > > > > >>>> they
> > > > > > >>>> manage?
> > > > > > >>>>
> > > > > > >>>> It seems like a user may not grant other users privileges that
> > > > > > >>>> exceed
> > > > > > >>>> their
> > > > > > >>>> own. Any ideas how to implement this?
> > > > > > >>>>
> > > > > > >>>> Perhaps they may clone their own roles and add further search
> > > > > > >>>> clauses,
> > > > > > >>>> but
> > > > > > >>>> have a readonly portion of the search clause that is AND'ed
> > > > > > >>>> with
> > > > > > >>>> whatever
> > > > > > >>>> they add.
> > > > > > >>>>
> > > > > > >>>> Or perhaps new roles get AND'ed with the original author's
> > > > > > >>>> current
> > > > > > >>>> priveleges when checking? User 'admin' creates 'ACME admin'
> > > > > > >>>> who
> > > > > > >>>> in
> > > > > > >>>> turn
> > > > > > >>>> creates 'bob'. Bob would have roles assigned by 'ACME admin'
> > > > > > >>>> but
> > > > > > >>>> the
> > > > > > >>>>
> > > > > > >>>> User.authorized(:view_users) would really be three calls:
> > > > > > >>>> admin.authorized(:view_users) -
> > > > > > >>>> !admin_acme.authorized(:view_users)
> > > > > > >>>> -
> > > > > > >>>>
> > > > > > >>>> !bob.authorized(:view_users)
> > > > > > >>>>
> > > > > > >>>> Any other clever ideas?
> > > > > > >>>
> > > > > > >>> --
> > > > > > >>> You received this message because you are subscribed to the
> > > > > > >>> Google
> > > > > > >>> Groups
> > > > > > >>> "foreman-dev" group.
> > > > > > >>> To unsubscribe from this group and stop receiving emails from
> > > > > > >>> it,
> > > > > > >>> send
> > > > > > >>> an
> > > > > > >>> email to foreman-dev+unsubscribe@googlegroups.com.
> > > > > > >>> For more options, visit https://groups.google.com/d/optout.
> > > > > > >
> > > > > > > --
> > > > > > > Marek
> > > > > > >
> > > > > > > --
> > > > > > > You received this message because you are subscribed to the
> > > > > > > Google
> > > > > > > Groups
> > > > > > > "foreman-dev" group.
> > > > > > > To unsubscribe from this group and stop receiving emails from it,
> > > > > > > send
> > > > > > > an
> > > > > > > email to foreman-dev+unsubscribe@googlegroups.com.
> > > > > > > For more options, visit https://groups.google.com/d/optout.
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups
> > > > "foreman-dev" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send
> > > > an
> > > > email to foreman-dev+unsubscribe@googlegroups.com.
> > > > For more options, visit https://groups.google.com/d/optout.
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "foreman-dev" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an
> > > email to foreman-dev+unsubscribe@googlegroups.com.
> > > For more options, visit https://groups.google.com/d/optout.
>
> --
> Marek
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
that would be bad. AND'ed