[SSSD] Design Discussion: Domains, users and groups over D-Bus

Dmitri Pal dpal at redhat.com
Wed Jan 28 19:34:55 UTC 2015


On 01/28/2015 02:00 PM, Pavel Brezina wrote:
>
> ----- Original Message -----
>> From: "Jakub Hrozek" <jhrozek at redhat.com>
>> To: sssd-devel at lists.fedorahosted.org
>> Sent: Wednesday, January 28, 2015 12:22:09 PM
>> Subject: Re: [SSSD] Design Discussion: Domains, users and groups over D-Bus
>>
>> On Wed, Jan 28, 2015 at 10:28:34AM +0100, Pavel Březina wrote:
>>> On 01/14/2015 04:19 PM, Pavel Březina wrote:
>>>> On 01/12/2015 03:51 PM, Pavel Březina wrote:
>>>>> On 12/16/2014 02:26 PM, Pavel Březina wrote:
>>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder
>>>>> I created a new design page to reduce size and increase readability in
>>>>> the original one. I would like to keep DBusResponder page mainly as a
>>>>> crossroad with links to other pages in the future so it is not swamped
>>>>> with too many details on everything.
>>>>>
>>>>> I will replace user and group design in DBusResponder with the following
>>>>> link if you agree:
>>>>>
>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
>>>>>
>>>>> It should cover everything we agreed on. If not, please tell me and I
>>>>> will add it.
>>>> New iteration is available at:
>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
>>> I think we should rethink the object paths. Currently it contains only $UID
>>> information which should be unique across all domain. Therefore we relay on
>>> sysdb_getpwuid, however, this function still requires domain.
>>>
>>> We can either iterate over all domains and use the first match, or we can
>>> add domain information into the object path:
>>>
>>> /ifp/Users/$domain/$uid
>> Is it about the object path only?
>>
>>  From application perspective, the UID might be the only input data they have
>> (think file ownership), we should provide a mean to retrieve a user
>> based on this data only. The fact that we use 'domains' is not
>> interesting for applications.
> Yes, it is only about the domain path. The object path can be obtained by uid
> search with Users.FindByID(id), not domain is required there.
>
> We can iterate through all the domains in the getters, but having the domain as a part of an object path is simply more convenient.
>
>
>> I don't have a problem with adding domain to the path, after all, the
>> user is not supposed to construct the paths himself, he ought to use the
>> Find() methods. But I think we shouldn't require the domain to be an
>> input parameter.
> I'm also thinking about more complex and more object oriented interface usage. Something like:
>
> ifp.Users.ListByName on /ifp/Users
> ifp.Users.ListByName on /ifp/$domain/Users
>
> The later can replace ListByDomainAndName(domain, filter, limit) method.
>
> User object path can then look like: /ifp/$domain/Users/$uid
>
> But that is probably too complex and overthought. What do you think?
>
>

As long as you can get users without of with domain specified I do not 
really have any preference.
>
>
>
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.




More information about the sssd-devel mailing list