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

Jakub Hrozek jhrozek at redhat.com
Wed Aug 13 08:03:41 UTC 2014


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.

Do I remember the conversation right?

Lukas, do you agree and can you prepare a patch?



More information about the sssd-devel mailing list