[SSSD] [PATCH] SDAP: Deref needn't be treated as critical

Jakub Hrozek jhrozek at redhat.com
Wed Aug 13 08:38:40 UTC 2014


On Wed, Aug 13, 2014 at 10:27:23AM +0200, Lukas Slebodnik wrote:
> On (13/08/14 10:03), Jakub Hrozek wrote:
> >On Mon, Aug 11, 2014 at 07:39:29AM +0200, Lukas Slebodnik wrote:
> >> On (09/08/14 23:05), Simo Sorce wrote:
> >> >On Sat, 2014-08-09 at 11:54 +0200, Jakub Hrozek wrote:
> >> >> On Fri, Aug 08, 2014 at 01:08:54PM +0200, Lukas Slebodnik wrote:
> >> >> > ehlo,
> >> >> >
> >> >> > The command line utility ldapsearch does not set option LDAP_CONTROL_X_DEREF as
> >> >> > critical.
> >> >> >
> >> >> > sssd performes similar ldap search as following command:
> >> >> >   sh-4.2$ ldapsearch -x -LLL -h 172.17.0.7 \
> >> >> >            -b 'cn=ref_grp1,ou=qagroup,dc=example,dc=com'
> >> >> >            -E '!deref=member:objectClass,cn,userPassword,gidNumber,member,modify
> >> >> > Timestamp,modifyTimestamp,uid' \
> >> >> >             objectClass,cn,userPassword,gidNumber,member,modifyTimestamp,modifyT
> >> >> > imestamp,uid
> >> >> > Critical extension is unavailable (12)
> >> >> > Additional information: critical control unavailable in context
> >> >> >
> >> >> > The most important is "exclamation mark" before extensions. It indicates
> >> >> > criticality. This caused problem when openldap server was older
> >> >> > openldap-2.4.23-34.el6. Dereference is performed successfully if extension is
> >> >> > not critical:  -E 'deref=member:objectClass ...
> >> >> >
> >> >> > Resolves:
> >> >> > https://fedorahosted.org/sssd/ticket/2383
> >> >> >
> >> >> > oneliner is attached.
> >> >> >
> >> >> > LS
> >> >>
> >> >> The patch looks good and was confirmed to work by our QE. Also works
> >> >> fine with my local tests (389-ds-base-1.3.2.16-1.fc20.x86_64 and
> >> >> openldap-2.4.39-3.fc20.x86_64)
> >> >
> >> >And what happens if the server does not give you back the control when
> >> >it return the results but performs a normal search ?
> >> >
> >> If the critical flag is enabled dereferencing will failed and individual
> >> lookups will be performed on the group.
> >> 
> >> This is only problem with old version of openldap (2.4.23-32). The critical
> >> flag works well with openldap-servers-2.4.39.
> >> 
> >> >The reason why the control is marked critical, IIRC, is that we expect
> >> >to get it back on reply, or it should fail.
> >> >
> >> >Shouldn't we rather leave the criticality bit and handle the error (by
> >> >downgrading to not use deref controls) if the server fails ?
> >> >
> >> We do with current master.
> >> 
> >> >Simo.
> >> >
> >> The surprising is that dereferencing is performed without flag: critical
> >> 
> >> $ ldapsearch -x -LLL -h 172.17.0.7 -b 'dc=example,dc=com' -E 'deref=member:uid' cn=ref_grp1
> >>                                        //                    ^^^
> >>                                        // As you can see there isn't flag: '!'
> >> dn: cn=ref_grp1,ou=qagroup,dc=example,dc=com
> >> # member: <uid=drefuser1>;uid=drefuser1,dc=example,dc=com
> >> 
> >> # member: <uid=drefuser2>;uid=drefuser2,dc=example,dc=com
> >> 
> >> # member: <uid=drefuser3>;uid=drefuser3,dc=example,dc=com
> >> 
> >> objectClass: extensibleObject
> >> objectClass: groupOfNames
> >> gidNumber: 10001
> >> cn: ref_grp1
> >> member: uid=drefuser1,dc=example,dc=com
> >> member: uid=drefuser2,dc=example,dc=com
> >> member: uid=drefuser3,dc=example,dc=com
> >> 
> >> LS
> >
> >After some more discussion on #sssd, we decided that it would be best to
> >try dereference with criticality flag and if it fails, disable
> >dereference altogether.
> What do you mean by disable dereference altogether?

Same effect as setting ldap_deref_threshold=0

> 
> >
> >Do I remember the conversation right?
> >
> >Lukas, do you agree and can you prepare a patch?
> I think we will need just to revert patch from this thread.

What about the problem our QE was seeing with old openldap servers,
then? Shouldn't we handle it gracefully?



More information about the sssd-devel mailing list