RFC Feature Planning: User Groups

Scott Seago sseago at redhat.com
Wed Apr 4 18:18:11 UTC 2012


On 04/04/2012 02:07 PM, Jason Guiditta wrote:
> On 04/04/12 13:54 -0400, Scott Seago wrote:
>> On 03/30/2012 09:50 AM, Scott Seago wrote:
>>> Rather than paste in the entire text, I'm just linking to the wiki 
>>> writeup. Please read the whole thing first and if you want to 
>>> comment on anything specific, quote it and comment on this thread.
>>>
>>>
>>> https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Adding_User_Groups 
>>>
>>>
>>>
>>> Scott
>>>
>> OK I've updated to take into account feedback from Imre, Jan, Jay, 
>> and Angus.
>>
>> In particular, we'll allow both LDAP and Local groups to exist 
>> concurrently (subject to config flags, so we can still lock this down 
>> to only one type). I've added consideration of dynamic user group 
>> lists managed via LDAP queries, but in the 'future plans' section, as 
>> it will probably not be included in the initial iteration.
>>
>> In addition, I've noted that, subject to availability of a scheduling 
>> infrastructure, I'd prefer the background re-sync to inline/blocking 
>> re-sync.
>>
>> Scott
>>
>
> Scott, couple minor questions/thoughts here:
>
> * what happens if an ldap usergroup is deleted on a sync (and I
>   would assume all permissions for a given user that was in that group
>   on any objects they own as well), but nobody else owns those
>   objects?  For example, Joes group is deleted, and he has some
>   deployables he created, and a few running instances.  Nobod else has
>   access to those objects, so what happens to them (especially the
>   running instances)?
>
So the result would be the same as would happen if an admin had manually 
removed the permission records. Taking LDAP out of the mix (since the 
same issue would happen with non-LDAP groups) we could imagine two sorts 
of cases:

1) group exists and members are removed: As members are removed from a 
group, those former members lose access to resources they only had by 
virtue of group membership. What happens when an admin removes the last 
member of the group? The group still exists, its permission grants 
exist, but they don't actually grant any real users access anymore.
2) admin deletes a group: In this case, all of the permission records 
assigned to the  group are removed.

In both cases, we won't touch running instances -- why should we? That 
would be like destroying a car just because someone took away the 
driver's keys.

In addition, recall that (unless someone revoked the permissions) the 
user who launched the instances will still have rights, as the user will 
be 'instance owner' and 'deployment owner' on the instances and 
deployments. Also, the admin will, as always, have access to the 
instances to reinstate permissions, etc.
> * This is probably out of scope, but I would hope we will include a
>   task(s) to make whatever controller changes are needed also provide
>   an api?
>
Yes, we should define the API here. We'll need API for 
creating/removing/altering groups, and (for local groups) 
adding/removing group members.

General question here -- going forward, are "build out API" tasks going 
to be done across the board at some point? Also, do we assume that 
_every_ new feature we add from now on includes implementing the basic 
APIs for the main objects associated with that feature?

> Aside from this, I think you have captured all the bits we have
> discussed, and looks like a pretty workable plan to me.
>
> -j




More information about the aeolus-devel mailing list