[Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't

Simo Sorce ssorce at redhat.com
Thu Sep 11 15:37:41 UTC 2014


On Thu, 2014-09-11 at 17:03 +0200, Martin Kosek wrote:
> Hello,
> 
> We have another important issue to resolve. Current FreeIPA 4.0.2 ACI settings
> cause older SSSD clients to fail as they get returned an LDAP deref call
> results without objectclass attribute and just with entryusn attribute. Details
> in https://fedorahosted.org/freeipa/ticket/4534. While I agree SSSD should be
> more tolerant in this case, it still breaks old clients which we should prevent.
> 
> There are 2 ways how to fix I currently see:
> 
> 1) Return objectclass for any entry, just like we do with operational attributes
> 
> This would include adding "objectclass" to "System: Read Timestamp and USN
> Operational Attributes". However, I am rather cautious about this approach as
> even though objectclass does not usually carry a secret information, we could
> still leak some information about our DIT to unprivileged user.

Our DIT is public and known, I see no problem.

> 2) Show objectclass+operational attributes in our Read ACIs
> Other way I see is to update *all* our Read permissions allowing reading
> objectclass attribute and also allow the chosen LDAP operational attribute.
> This would let the LDAP caller to always get either all these discussed
> attributes but none at all.
> 
> 
> Do we want to do this? Any other (better) idea how to approach it?

I honestly am not sure I understand the distinction between 1 and 2, can
you provide the actual ACIs or a behavior example ?

Simo.





More information about the Freeipa-devel mailing list