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

Dmitri Pal dpal at redhat.com
Fri Jan 9 00:51:26 UTC 2015


On 01/08/2015 03:16 PM, Pavel Březina wrote:
> On 01/08/2015 07:44 PM, Jakub Hrozek wrote:
>> On Thu, Jan 08, 2015 at 09:35:42AM -0500, Dmitri Pal wrote:
>>> On 01/08/2015 04:05 AM, Jakub Hrozek wrote:
>>>> On Wed, Jan 07, 2015 at 03:41:01PM -0500, Simo Sorce wrote:
>>>>> On Wed, 07 Jan 2015 15:25:30 -0500
>>>>> Dmitri Pal <dpal at redhat.com> wrote:
>>>>>
>>>>>> On 01/07/2015 03:05 PM, Simo Sorce wrote:
>>>>>>> On Tue, 06 Jan 2015 09:59:08 -0500
>>>>>>> Dmitri Pal <dpal at redhat.com> 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
>>>>>>> reasonable
>>>>>>>
>>>>>>>> - I do not think we should rely on enumeration. I think we should
>>>>>>>> do a lookup since these operations will be rare.
>>>>>>> Nope.
>>>>>>> This is the same thinking the implementers of the nss interface 
>>>>>>> went
>>>>>>> through. And then users started using enumeration all the time.
>>>>>>>
>>>>>>> It may be ok to let users programmatically force full enumeration
>>>>>>> somehow. But the default should be to return only what is in cache.
>>>>>>> If you do otherwise people will test applications using * with 3
>>>>>>> users on the system and then fail spectacularly when there are
>>>>>>> actually 100K users in the directory.
>>>>>> I think there is a problem with the approach you suggest.
>>>>>>
>>>>>> Say there is an application that allows you to list groups starting
>>>>>> with a letter. It is used to define roles for application
>>>>>> administration.
>>>>>>
>>>>>> Assume that there is a group "Agroup". It is a new group that does
>>>>>> not have users yet. But it was created for use with the application
>>>>>> so that roles can be associated with this group. The admin of the
>>>>>> application thus wants to start using it.
>>>>>> This group will never be looked up if "A*" query will be run against
>>>>>> cache because it will not end up in cache. That would force admin to
>>>>>> turn full enumeration on SSSD. This is bad.
>>>>> What matters is the '*' does not do enumeration, if 'ABC*' causes an
>>>>> online lookup it is fine imo.
>>>> Yes, this is exactly what I was proposing. However, handling 'ABC*' on
>>>> the back end side must be implemented, currently we only handle a 
>>>> single
>>>> entry or enumeration.
>>>>
>>>> I might have confused you because I proposed to first finish the DBus
>>>> *responder* work and temporarily require enumeration until we 
>>>> extend the
>>>> back end.
>>>>
>>>> I hope it makes sense now.
>>>
>>> As long as the work is bound to the same milestone the order does not
>>> matter.
>>
>> OK, I filed https://fedorahosted.org/sssd/ticket/2553 into the same
>> milestone.
>
> This brings another question. Because we are talking about 
> ListUsersByFilter() that returns a list of object paths the only thing 
> that is needed to construct such path is UID. So we can avoid 
> membership evaluation here which would reduce load and processing time.
>
> The caller will be probably interested mostly in user name, is that 
> correct? So we can skip membership evaluation at all unless group 
> property is requested.

Yes.

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