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

Lukas Slebodnik lslebodn at redhat.com
Wed Aug 13 14:13:52 UTC 2014


On (13/08/14 16:10), Jakub Hrozek wrote:
>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?
Agree.

BTW. here is output from ldap search utility.
As you will see, DEREF is suported by openldap server, but does not work with
critical flag.

sh-4.2$ ldapsearch -LLL -h 172.17.0.9 -x -b "" -s base supportedControl
dn:
supportedControl: 1.3.6.1.4.1.4203.666.5.16
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 1.3.6.1.4.1.4203.1.10.1
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.2.826.0.1.3344810.2.3
supportedControl: 1.3.6.1.1.13.2
supportedControl: 1.3.6.1.1.13.1
supportedControl: 1.3.6.1.1.12

sh-4.2$ grep "1.3.6.1.4.1.4203.666.5.16" /usr/include/ldap.h
#define LDAP_CONTROL_X_DEREF                    "1.3.6.1.4.1.4203.666.5.16"

sh-4.2$ ldapsearch -x -LLL -h 172.17.0.9 -b 'dc=example,dc=com' -E '!deref=member:cn,uid' cn=ref_grp1 cn,uid
Critical extension is unavailable (12)
Additional information: critical control unavailable in context

sh-4.2$ ldapsearch -x -LLL -h 172.17.0.9 -b 'dc=example,dc=com' -E 'deref=member:cn,uid' cn=ref_grp1 cn,uid
dn: cn=ref_grp1,ou=qagroup,dc=example,dc=com
# member: <cn=Dref_User1>;<uid=drefuser1>;uid=drefuser1,dc=example,dc=com

# member: <cn=Dref_User2>;<uid=drefuser2>;uid=drefuser2,dc=example,dc=com

//snip

sh-4.2$ echo $?
0

LS



More information about the sssd-devel mailing list