[SSSD] user and group precedence issue

Simo Sorce simo at redhat.com
Wed Mar 14 22:27:05 UTC 2012


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.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list