[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#5760) attribute hiding in rwm overlay



brett.maxfield@gmail.com wrote:
> --0016e65206024a6d9d0462d5c0d0
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> 
> I have re-tested with recent RE24 and this still happens.
> 
> Assuming the config (database meta, and map instead of rwm-map shows similar
> problem) :
> 
> database        ldap
> suffix          "c=AU"
> uri             "ldap://127.0.0.1:390/c=AU";

You messed things up a little bit: back-ldap does not allow the DN part 
of the URI.

> overlay rwm
> 
> rwm-map attribute cn *
> rwm-map attribute sn *
> rwm-map attribute givenName *
> rwm-map attribute *
> 
> rwm-map objectclass inetOrgPerson *
> rwm-map objectclass organisationalUnit *

s/organisationalUnit/organizationalUnit/: this raises a warning.

> rwm-map objectclass organization *
> rwm-map objectclass country *
> rwm-map objectclass *
> 
> I have a standard LDAP with standard inetOrgPerson style schemas on ldap://
> 127.0.0.1:390/c=AU with some dummy data, and when i query the source
> directory i get sensible results:
> 
> suse:/usr/local/etc/openldap # ldapsearch -H ldap://127.0.0.1:390 -x -b
> 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' '*'
> # extended LDIF
> #
> # LDAPv3
> # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree
> # filter: (objectclass=*)
> # requesting: *
> #
> 
> # test00496, support, openldap, AU
> dn: cn=test00496,ou=support,o=openldap,c=AU
> objectClass: inetOrgPerson
> cn: test00496
> givenName: test00496
> uid: test00496
> sn: test00496lname
> displayName: test00496 test00496lname
> userPassword:: bm92ZWxs
> 
> # search result
> search: 2
> result: 0 Success
> 
> # numResponses: 2
> # numEntries: 1
> 
> When i query the meta directory, i get no attributes (* or + or *,+, in the
> requested attributes all return no attributes as below) :
> 
> ldapsearch -H ldap://127.0.0.1:391 -x -b
> 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' '*'
> # extended LDIF
> #
> # LDAPv3
> # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree
> # filter: (objectclass=*)
> # requesting: *
> #
> 
> # test00496, support, openldap, AU
> dn: cn=test00496,ou=support,o=openldap,c=AU
> 
> # search result
> search: 2
> result: 0 Success
> 
> # numResponses: 2
> # numEntries: 1
> 
> But if i query the meta directory explicitly for some attributes (no * +),
> it works, i get :
> 
>  ldapsearch -H ldap://127.0.0.1:391 -x -b
> 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' cn sn firstName
> # extended LDIF
> #
> # LDAPv3
> # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree
> # filter: (objectclass=*)
> # requesting: cn sn firstName
> #
> 
> # test00496, support, openldap, AU
> dn: cn=test00496,ou=support,o=openldap,c=AU
> cn: test00496
> sn: test00496lname
> 
> # search result
> search: 2
> result: 0 Success
> 
> # numResponses: 2
> # numEntries: 1
> 
> So i conclude then that the default attribute lists of *, +, or *,+ are
> somehow being lost by backend meta or overlay rwm ?
> 
> Probably * and + (or *,+) should be expanded to the list of user or
> administrative attributes (respectively) by meta/rwm first, specifically
> those that are allowed by "map attribute" lines, before being handed to the
> real directory (helpful to performance if the backend directory has many
> attributes, that the meta directory is not interested in).
> 
> This is also why attributes don't appear in a GUI browser for me, if i am
> using a GUI browser, as they commonly use *,+ as their default.

Well, if you don't request any attribute, those that are mapped appear. 
  I've modified slapo-rwm to pass thru special attribute names ("*", 
"+", "1.1") in order to defer their mapping when results are returned. 
This looks simpler than detecting whether non-mapped attrs are filtered 
and, in tat case, replace "*" by the mapped attributes, although the 
latter could be an optimization.

A fix is in HEAD (affecting back-meta and slapo-rwm independently). 
Please test.  Unfortunately it seems to be too late for OpenLDAP 2.4.14.

p.


Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Fax:     +39 0382 476497
Email:   ando@sys-net.it
-----------------------------------