[SSSD] user and group precedence issue

Stephen Gallagher sgallagh at redhat.com
Wed Mar 14 22:00:45 UTC 2012


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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120314/8f3cfc37/attachment.sig>


More information about the sssd-devel mailing list