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

Dmitri Pal dpal at redhat.com
Tue Dec 16 23:55:56 UTC 2014


On 12/16/2014 08:26 AM, Pavel Březina wrote:
> https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder
>
> Hi,
> I have take the following tikcet that is about implementing D-Bus 
> calls for domains, users and groups. I have some questions.
>
> https://fedorahosted.org/sssd/ticket/2150
>
> *List and Find methods interface*
> At this moment we implement all List* and Find* methods on 
> /org/freedesktop/sssd/infopipe and org.freedesktop.sssd.infopipe 
> interface.
>
> The patches I sent today enables having support for different 
> interfaces on /path and /path/*, therefore we can implement the 
> methods as:
>
> /infopipe/Users infopipe.Users.ListUsers()
> /infopipe/Users/$UID user specific methods and properties
>
> instead of:
> /infopipe infopipe.ListUsers()
> /infopipe/Users/$UID user specific methods and properties
>
> I think it make sense. Is this something we want?

If this is a question about API naming then I do not think there are any 
specific requirements.

>
> *Domains*
> The interface from the design page is already implemented. Is there 
> any method or property that is missing?

List domains with a filter which a regular expressions is the 
requirement. Filter can be *.
You can use any syntax for regex. For domains the filter is optional.

>
> *Users*
> Do we want also to have methods ListDomainUsers() and ListUsers() 
> without the name filter?

I think this is dangerous. I would say no.

>
> Do we want some other filter options as well?

I think we want SSSD to return an error is it thinks a filter is too 
short. It should be at least on character, may be 2-3. We would need to 
check with RHEV and others.
The caller would need to be able to handle the error.

>
> Should extraAttributes be present in Properties.GetAll() output?

Yes, if they are configured to be exposed.

>
> What is UpdateGroupList() supposed to do?

I think it is to refresh the cache with most recent group info for a 
specific user. I suspect it also returns the updated list.

>
> Property groups - do we really want to return list of object paths 
> instead of pure group names? I think that more common use case will 
> want only the names. Or we can even implement both.

For now we need just names. If we need objects we can add an interface 
later.

I am not sure if we want to have an option to indicate that local cache 
is good enough and call does not need to go over the wire and can be 
served by cached data only.

>
> *Groups*
> Basically the same questions and per Users.

Same answers.

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