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

Jakub Hrozek jhrozek at redhat.com
Wed Aug 13 14:10:32 UTC 2014


On Wed, Aug 13, 2014 at 03:57:15PM +0200, Lukas Slebodnik wrote:
> On (13/08/14 10:38), Jakub Hrozek wrote:
> >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=group,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=group,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?
> 
> The only problem with old openldap is that deref *DOES NOT* work with critical
> flag, but on the other hand sssd returns correct result.
> This is a behaviour of sssd master with reverted patch from this thread.

Thanks, that's a very helpful explanation. Then I propose we:
    1) revert the patch
    2) for downstream, add some documentation that certain openldap
    servers are broken and if you use those, you need to disable
    dereference

Sounds like a plan?



More information about the sssd-devel mailing list