[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-devel
Subject:    Re: ldap_get_values() called on binary data - does this return an error, or garbage data?
From:       Ondřej Kuzník <ondra () mistotebe ! net>
Date:       2024-04-03 13:42:13
Message-ID: Zg1ctbjFVGASuCCs () mistotebe ! net
[Download RAW message or body]

On Wed, Apr 03, 2024 at 02:08:15PM +0100, Graham Leggett wrote:
> On 03 Apr 2024, at 13:03, Ondřej Kuzník <ondra@mistotebe.net> wrote:
> 
>>> This has been historically vague - first off, what happens if an
>>> attempt is made to call ldap_get_values() on binary data, do you get
>>> an error, or garbage data? The source isn't giving me a clear answer.
>> 
>> Hi Graham,
>> in this case binary data means embedded NULs (\0) can be found: given
>> that what you get back is a naive char * for each value, you stand to
>> lose information about whether that NUL is part of the value or a
>> string terminator.
> 
> So that means garbage data is returned.

Not completely, you just ignore the rest of the value if you use
anything that's strlen()-based.

> So am I right in understanding there is no way to ask the server "what
> type is this attribute you just gave me, is this arbitrary octets or a
> NUL terminated string"?

There's server schema, otherwise no.

Are you processing the values or just treating them as opaque data? If
the latter, why do you care? If you're processing it, you should know
whether you expect a (UTF-8, IA5, ...) string or something else.

Regardless, the ldap_get_values API is legacy, when things were expected
to be just strings and I guess it makes some tasks easier for lazy(?)
programmers. ldap_get_values_len gives you explicit information about
the length of the data, enabling safer processing. Certainly doesn't
stop you from handling strings - the .bv_vals are exactly what you'd
obtain from ldap_get_values.

>> You're welcome to propose better wording if you can make it clearer to a
>> reasonably competent C developer (I'm sure we can assume that they
>> understand how strings are laid out etc.)
> 
> The reason this matters has nothing to do with reasonably competent C
> developers, but rather options given to end users.
> 
> If the end user is allowed to provide an attribute in a configuration
> file, do I force the end user to know about binary values (as is
> common now), or is there a way I can be nice to the end user and have
> the system behave sensibly based on whether the return data is a
> string or binary?

It is up to the developer how they intend to handle the returned data,
see above. The user has no influence over this whatsoever. If the
application lets the user to specify an arbitrary attribute, then it has
to be written accordingly (even if it's only to check that
strlen(.bv_val) == .bv_len), anything else is asking for trouble.

Regards,

-- 
Ondřej Kuzník
Senior Software Engineer
Symas Corporation                       http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
[prev in list] [next in list] [prev in thread] [next in thread]