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

Simo Sorce simo at redhat.com
Sun Aug 10 03:05:17 UTC 2014


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 ?

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 ?

Simo.

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




More information about the sssd-devel mailing list