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

Pavel Březina pbrezina at redhat.com
Fri Jan 9 09:26:22 UTC 2015


On 01/09/2015 09:59 AM, Jakub Hrozek wrote:
> On Thu, Jan 08, 2015 at 09:16:53PM +0100, 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, we know updating membership is a costly operation, that's why there is a
> separate method for that.

Ok. I will prepare a design page that will cover all this.




More information about the sssd-devel mailing list