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

Dmitri Pal dpal at redhat.com
Tue Jan 6 14:59:08 UTC 2015


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





-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.




More information about the sssd-devel mailing list