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

Jakub Hrozek jhrozek at redhat.com
Wed Jan 28 11:22:09 UTC 2015


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.



More information about the sssd-devel mailing list