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

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



--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";

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

Cheers
Brett

On Sun, Jan 25, 2009 at 12:53 AM, Pierangelo Masarati <ando@sys-net.it>wrote:

> [please reply to the ITS, otherwise issues can't be tracked]
>
> Brett @Google wrote:
>
>> HI Ando,
>>
>> Do you know if the fix for ITS#5760 (says fixed for RE24 and HEAD) make it
>> into RE24 in time for the 2.4.13 release ?
>>
>
> apparently, yes.
>
>  If so, i can still see the behaviour here with 2.4.13, i can see
>> operational
>> attributes, but non non-operational attributes, when mapping both
>> objectclass and attribute..
>>
>> Bug seems to be focused on using of *, rather than an explicit list of
>> non-operational attrs which works, ie :
>>
>> I can search for attributes with * ( get all non-operational attributes )
>> and don't get any non-operational attributes, whereas explicitly adding
>> any
>> non-operational attribute will result i a search returning the named
>> values,
>> which is allowable via the objectclass maps.
>>
>> seems to work the same (omitting non-oprational attrs), even if i dont
>> specufy the objectclass rwm maps.
>>
>
> Not sure I understand.  Can you post simple (both working and not working)
> examples?
>
>
> 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
> -----------------------------------
>
>

--0016e65206024a6d9d0462d5c0d0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I have re-tested with recent RE24 and this still happens. <br><br>Assuming =
the config (database meta, and map instead of rwm-map shows similar problem=
) :<br><br>database&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ldap<br>suffi=
x&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;c=3DAU&quot;<=
br>uri&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; &quot;ldap://<a href=3D"http://127.0.0.1:390/c=3DAU";>127.0.0.1:390/c=3D=
AU</a>&quot;<br>
<br>overlay rwm<br><br>rwm-map attribute cn *<br>rwm-map attribute sn *<br>=
rwm-map attribute givenName *<br>rwm-map attribute *<br><br>rwm-map objectc=
lass inetOrgPerson *<br>rwm-map objectclass organisationalUnit *<br>rwm-map=
 objectclass organization *<br>
rwm-map objectclass country *<br>rwm-map objectclass *<br><br>I have a stan=
dard LDAP with standard inetOrgPerson style schemas on ldap://<a href=3D"ht=
tp://127.0.0.1:390/c=3DAU">127.0.0.1:390/c=3DAU</a> with some dummy data, a=
nd when i query the source directory i get sensible results:<br>
<br>suse:/usr/local/etc/openldap # ldapsearch -H ldap://<a href=3D"http://1=
27.0.0.1:390">127.0.0.1:390</a> -x -b &#39;cn=3Dtest00496,ou=3Dsupport,o=3D=
openldap,c=3DAU&#39; &#39;(objectclass=3D*)&#39; &#39;*&#39;<br># extended =
LDIF<br>
#<br># LDAPv3<br># base &lt;cn=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU=
&gt; with scope subtree<br># filter: (objectclass=3D*)<br># requesting: *<b=
r>#<br><br># test00496, support, openldap, AU<br>dn: cn=3Dtest00496,ou=3Dsu=
pport,o=3Dopenldap,c=3DAU<br>
objectClass: inetOrgPerson<br>cn: test00496<br>givenName: test00496<br>uid:=
 test00496<br>sn: test00496lname<br>displayName: test00496 test00496lname<b=
r>userPassword:: bm92ZWxs<br><br># search result<br>search: 2<br>result: 0 =
Success<br>
<br># numResponses: 2<br># numEntries: 1<br><br>When i query the meta direc=
tory, i get no attributes (* or + or *,+, in the requested attributes all r=
eturn no attributes as below) :<br><br>ldapsearch -H ldap://<a href=3D"http=
://127.0.0.1:391">127.0.0.1:391</a> -x -b &#39;cn=3Dtest00496,ou=3Dsupport,=
o=3Dopenldap,c=3DAU&#39; &#39;(objectclass=3D*)&#39; &#39;*&#39;<br>
# extended LDIF<br>#<br># LDAPv3<br># base &lt;cn=3Dtest00496,ou=3Dsupport,=
o=3Dopenldap,c=3DAU&gt; with scope subtree<br># filter: (objectclass=3D*)<b=
r># requesting: *<br>#<br><br># test00496, support, openldap, AU<br>dn: cn=
=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU<br>
<br># search result<br>search: 2<br>result: 0 Success<br><br># numResponses=
: 2<br># numEntries: 1<br><br>But if i query the meta directory explicitly =
for some attributes (no * +), it works, i get :<br><br>&nbsp;ldapsearch -H =
ldap://<a href=3D"http://127.0.0.1:391";>127.0.0.1:391</a> -x -b &#39;cn=3Dt=
est00496,ou=3Dsupport,o=3Dopenldap,c=3DAU&#39; &#39;(objectclass=3D*)&#39; =
cn sn firstName<br>
# extended LDIF<br>#<br># LDAPv3<br># base &lt;cn=3Dtest00496,ou=3Dsupport,=
o=3Dopenldap,c=3DAU&gt; with scope subtree<br># filter: (objectclass=3D*)<b=
r># requesting: cn sn firstName<br>#<br><br># test00496, support, openldap,=
 AU<br>
dn: cn=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU<br>cn: test00496<br>sn:=
 test00496lname<br><br># search result<br>search: 2<br>result: 0 Success<br=
><br># numResponses: 2<br># numEntries: 1<br><br>So i conclude then that th=
e default attribute lists of *, +, or *,+ are somehow being lost by backend=
 meta or overlay rwm ?<br>
<br>Probably * and + (or *,+) should be expanded to the list of user or adm=
inistrative attributes (respectively) by meta/rwm first, specifically those=
 that are allowed by &quot;map attribute&quot; lines, before being handed t=
o the real directory (helpful to performance if the backend directory has m=
any attributes, that the meta directory is not interested in).<br>
<br>This is also why attributes don&#39;t appear in a GUI browser for me, i=
f i am using a GUI browser, as they commonly use *,+ as their default.<br><=
br>Cheers<br>Brett<br><br><div class=3D"gmail_quote">On Sun, Jan 25, 2009 a=
t 12:53 AM, Pierangelo Masarati <span dir=3D"ltr">&lt;<a href=3D"mailto:and=
o@sys-net.it">ando@sys-net.it</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">[please reply to =
the ITS, otherwise issues can&#39;t be tracked]<div class=3D"Ih2E3d"><br>
<br>
Brett @Google wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
HI Ando,<br>
<br>
Do you know if the fix for ITS#5760 (says fixed for RE24 and HEAD) make it<=
br>
into RE24 in time for the 2.4.13 release ?<br>
</blockquote>
<br></div>
apparently, yes.<div class=3D"Ih2E3d"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If so, i can still see the behaviour here with 2.4.13, i can see operationa=
l<br>
attributes, but non non-operational attributes, when mapping both<br>
objectclass and attribute..<br>
<br>
Bug seems to be focused on using of *, rather than an explicit list of<br>
non-operational attrs which works, ie :<br>
<br>
I can search for attributes with * ( get all non-operational attributes )<b=
r>
and don&#39;t get any non-operational attributes, whereas explicitly adding=
 any<br>
non-operational attribute will result i a search returning the named values=
,<br>
which is allowable via the objectclass maps.<br>
<br>
seems to work the same (omitting non-oprational attrs), even if i dont<br>
specufy the objectclass rwm maps.<br>
</blockquote>
<br></div>
Not sure I understand. &nbsp;Can you post simple (both working and not work=
ing) examples?<div><div></div><div class=3D"Wj3C7c"><br>
<br>
p.<br>
<br>
<br>
Ing. Pierangelo Masarati<br>
OpenLDAP Core Team<br>
<br>
SysNet s.r.l.<br>
via Dossi, 8 - 27100 Pavia - ITALIA<br>
<a href=3D"http://www.sys-net.it"; target=3D"_blank">http://www.sys-net.it</=
a><br>
-----------------------------------<br>
Office: &nbsp;+39 02 23998309<br>
Mobile: &nbsp;+39 333 4963172<br>
Fax: &nbsp; &nbsp; +39 0382 476497<br>
Email: &nbsp; <a href=3D"mailto:ando@sys-net.it"; target=3D"_blank">ando@sys=
-net.it</a><br>
-----------------------------------<br>
<br>
</div></div></blockquote></div><br>

--0016e65206024a6d9d0462d5c0d0--