[SSSD] user and group precedence issue

Dmitri Pal dpal at redhat.com
Wed Mar 14 22:43:28 UTC 2012


On 03/14/2012 06:27 PM, Simo Sorce wrote:
> On Wed, 2012-03-14 at 18:00 -0400, Stephen Gallagher wrote:
>> On Wed, 2012-03-14 at 16:36 -0400, Simo Sorce wrote:
>>> On Wed, 2012-03-14 at 21:17 +0100, Olivier wrote:
>>>> Ok, I see the logic now ( although I'm not completely
>>>> convinced from a practical point of view to be honnest :
>>>> a user name could be defined somewhere else, in a
>>>> referal ldap for example. In that case, should it be an
>>>> overall group consistency problem if a memberuid was
>>>> uknown because a referal server is not accessible ? ).
>>>>
>>> memberuid cannot be resolved through a referral as it cannot contain a
>>> DN :-)
>>> however if you use the "member" attribute and rfc2307bis you could end
>>> up chasing a referral that is temporarily broken. In that case you'd
>>> have a resolution issue, not an "unknown" member.
>>>
>>> I am not sure how sssd would handle a referral problem in this case,
>>> hopefully it would recognize the problem and just use a previously
>>> cached value. If it is the first lookup it would have no choice but to
>>> pretend the member did not exist until the next lookup.
>> Right now we can't handle this safely. It's a limitation of using the
>> internal openldap referral chasing. As far as we see as a consumer, the
>> entry doesn't exist, and we have to treat it on the client as LDAP
>> definitively asserting that the user does not exist, and therefore must
>> delete it from the local cache.
>>
>> I'm trying to work out ways to resolve this when we rewrite the referral
>> processing with our own implementation.
> Thanks,
> should we open a ticket specifically about this issue so we A) do not
> forget and B) can add a test case ?
>
> Simo.
>
https://fedorahosted.org/sssd/ticket/860#comment:8

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/






More information about the sssd-devel mailing list