Re: (ITS#5927) assertion error when using pcache

[mhardin@symas.com]

On Feb 7, 2009, at 3:24 AM, Pierangelo Masarati wrote:

> mhardin@symas.com wrote:
>> Some additional information:
>> Some objects being returned from AD have very large multi-valued   
>> attributes (for example, member). AD is returning them in the  
>> ";range"  format, but they are not getting past back-meta. For  
>> example, a direct  search for the object in AD will return stuff  
>> like this:
>> member;range=0-1499: CN=Alice Bar,OU=My-Company-Accounts,OU=User   
>> Accounts,OU=Common,DC=my-company,DC=com
>> but doing the same search through slapd/back-meta using the same   
>> credentials, the member attribute is not displayed at all. There  
>> are  no attribute maps in place that would cause this.
>
> If this is the cause, then back-meta should try to register the  
> attribute name as a "proxied" attribute type, and slapd should be  
> unable to correctly decode it because it contains a "=".  Back-meta  
> in the end should just ignore the whole attribute.
>

Thanks, Pierangelo. That led me to ITS#5472 and several other postings  
about the same issue. In particular:

 > [Petter Reinholdtsen said]
 >> This notation is not handled by ldap_get_values(), and it return
 >> NULL, resulting in a group with zero members.

 > [Kurt Zielenga replied]
 > This is proper and well-intended behavior.  You asked for values of
 > returned under the attribute description "member", not the (invalid)
 > attribute description "member;range=0-1499".  Two attribute
 > descriptions which share the same attribute type do not necessarily
 > refer to the same attribute.

This clearly explains the assertion pcache is reporting. Well-intended  
behavior or not, there is a problem here because pcache takes down the  
server whenever it encounters attribute values of this form. Given  
Kurt's later comments about the provenance and ancestry of this  
"standard", it seems to me the right thing for back-meta (and back- 
ldap, for that matter) to do might be to just make the attribute  
completely disappear. Appropriate messages output in debug mode or at  
a particular log level might announce the fact that the attribute is  
being disappeared. The pcache overlay, for its part, instead of  
asserting, might instead log a warning and refuse to cache the object.

Sound reasonable?

-Matt


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