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

Lukas Slebodnik lslebodn at redhat.com
Wed Aug 13 08:27:23 UTC 2014


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?

>
>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.

LS



More information about the sssd-devel mailing list