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

Pavel Březina pbrezina at redhat.com
Wed Jan 7 10:07:05 UTC 2015


On 01/06/2015 03:59 PM, Dmitri Pal wrote:
> On 01/06/2015 05:54 AM, Jakub Hrozek wrote:
>> On Tue, Jan 06, 2015 at 11:31:55AM +0100, Pavel Březina wrote:
>>>>> *Users*
>>>>> Do we want also to have methods ListDomainUsers() and ListUsers()
>>>>> without
>>>>> the name filter?
>>>> To list all? What about using '*' for that?
>>> We can implement it this way internally, but exposing an easier way
>>> to the
>>> consumers is nice, imho.
>> I'm not too opposed, although I prefer minimal APIs.
>>
>>> However, do we actually want to allow to list all users? As Dmitri
>>> suggested
>>> we may want to require the minimum filter length since the number of
>>> users
>>> may be very high. The maximum D-Bus message is 128MiB so I think we
>>> are good
>>> there but I think it can be very time consuming to return all users
>>> without
>>> some sort of paging.
>> This feature is internally dependant on enumerate=true, where we already
>> store all standard POSIX attributes (struct passwd, struct group)
>> in-memory, do you think the D-Bus "enumeration" provides that much
>> overhead?
>>
>> Paging would be really complex, we'd need to store the full results
>> in-memory per-client anyway and then pass around some kind of cookie to
>> resume iteration..
>>
>> In a centralized environment, I wouldn't expect the listing commands to
>> be used that commonly. Greeters or login managers (gdm) would typically
>> use the cached users instead. Some applications (Hi, RHEV-M!) choose to
>> display all their users in some kind of table and then I would expect
>> them to implement paging themselves:
>>
>> for letter in a..z:
>>      users = ListUsersByNameFilter($letter)
>>
>>>>> Do we want some other filter options as well?
>>>> In the design I wanted to keep the filtering simple. Unless we receive
>>>> some other requirements..
>>> Yes, you suggested to allow only asterisk. Implement full regular
>>> expression
>>> efficiently as Dmitri would be quite problematic since ldb doesn't
>>> support
>>> regex lookup thus we would have to do this ourselves and therefore we
>>> would
>>> loose indices, or am I wrong?
>> I guess we'd have to grab all the entries and filter them ourselves..
>>
>> (Yes, this is the reason I chose the asterisk notation in the first
>> place)
>> _______________________________________________
>> sssd-devel mailing list
>> sssd-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>
> Several points:
>
> - IMO having a full regular expression support will be an overhead.
> - "Begins with" filtering with * to indicate the remaining part is good
> enough
> - I do not think we should rely on enumeration. I think we should do a
> lookup since these operations will be rare.

In my opinion:

List methods (i.e. those that return list of objects) should return only 
those objects that are already cached. If the caller wants all of them, 
enumeration should be turned on.

Find methods (i.e. those that return single object) can perform a 
lookup, similar to what nss responder does.

> - SSSD should have a configuration option that specifies how short the
> filter can be  - default 3 characters (number of characters without
> asterisk). If application provided a shorter filter becuase user typed
> less characters SSSD would return error indicating that filter is too
> short. We would need to teach oVirt to respect such errors.
> - We need to review this with Jan, Barak and Alon.




More information about the sssd-devel mailing list