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.
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.