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

Pavel Březina pbrezina at redhat.com
Thu Jan 29 10:26:03 UTC 2015


On 01/28/2015 08:56 PM, Jakub Hrozek wrote:
> On Wed, Jan 28, 2015 at 02:00:59PM -0500, 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?
>
> I don't think this is required, meh :-)
>
> The only thing that comes to mind wrt the object path is that the object
> path might be the identifier that we use for object caching. But then I
> don't suppose subdomains can be renamed with the current code at all..

OK. I amended the design page to reflex /ifp/Users/$DOMAIN/$UID object path.




More information about the sssd-devel mailing list