Issue 7764 - RFE: library lber method which returns the ber size even if the ber is overflown
Summary: RFE: library lber method which returns the ber size even if the ber is overflown
Status: UNCONFIRMED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: libraries (show other issues)
Version: unspecified
Hardware: All All
: --- enhancement
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-13 21:42 UTC by nhosoi@gmail.com
Modified: 2020-03-20 17:51 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description nhosoi@gmail.com 2013-12-13 21:42:03 UTC
Full_Name: Noriko Hosoi
Version: 2.4.35-4
OS: Fedora 18
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (209.132.181.86)


We use the OpenLdap library in our software.  LDAP clients could send too large
ber and cause LBER_OVERFLOW (or LBER_DEFAULT) to the lber APIs.  We'd like to
learn how large the ber size we should prepare from the error.  When we look
into the BerElement ber using gdb, ber->ber_len stores the value. But the value
is not returned to the caller when the API fails, e.g., by the overflow.  Could
it be possible to have a way to retrieve the ber size under any condition?
Comment 1 Howard Chu 2013-12-15 11:58:05 UTC
nhosoi@gmail.com wrote:
> Full_Name: Noriko Hosoi
> Version: 2.4.35-4
> OS: Fedora 18
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (209.132.181.86)
>
>
> We use the OpenLdap library in our software.  LDAP clients could send too large
> ber and cause LBER_OVERFLOW (or LBER_DEFAULT) to the lber APIs.  We'd like to
> learn how large the ber size we should prepare from the error.  When we look
> into the BerElement ber using gdb, ber->ber_len stores the value. But the value
> is not returned to the caller when the API fails, e.g., by the overflow.  Could
> it be possible to have a way to retrieve the ber size under any condition?

That doesn't sound like OpenLDAP, we have no LBER_OVERFLOW error code. Nor do 
we have any particular size limits on a BerElement, other than fitting into a 
long.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Comment 2 nhosoi@gmail.com 2013-12-16 18:19:50 UTC
Thank you, Howard!

You are right.  We are not getting LBER_OVERFLOW, but having the return
code LBER_DEFAULT and "errno == ERANGE".  Also, indeed there is no
particular size limits in openldap lber library unless setting the max
incoming ber size with this API:
    ber_sockbuf_ctrl(sockbuf, LBER_SB_OPT_SET_MAX_INCOMING, &maxsize);

We'd like to avoid receiving, e.g., 100MB ber's, but we'd like to also have
a method to log the rejected incoming ber size just in case the
administrator may want to allow to receive it.

Best regards,
--Noriko Hosoi


On Sun, Dec 15, 2013 at 3:58 AM, Howard Chu <hyc@symas.com> wrote:

> nhosoi@gmail.com wrote:
>
>> Full_Name: Noriko Hosoi
>> Version: 2.4.35-4
>> OS: Fedora 18
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (209.132.181.86)
>>
>>
>> We use the OpenLdap library in our software.  LDAP clients could send too
>> large
>> ber and cause LBER_OVERFLOW (or LBER_DEFAULT) to the lber APIs.  We'd
>> like to
>> learn how large the ber size we should prepare from the error.  When we
>> look
>> into the BerElement ber using gdb, ber->ber_len stores the value. But the
>> value
>> is not returned to the caller when the API fails, e.g., by the overflow.
>>  Could
>> it be possible to have a way to retrieve the ber size under any condition?
>>
>
> That doesn't sound like OpenLDAP, we have no LBER_OVERFLOW error code. Nor
> do we have any particular size limits on a BerElement, other than fitting
> into a long.
>
> --
>   -- Howard Chu
>   CTO, Symas Corp.           http://www.symas.com
>   Director, Highland Sun     http://highlandsun.com/hyc/
>   Chief Architect, OpenLDAP  http://www.openldap.org/project/
>
Comment 3 Quanah Gibson-Mount 2017-04-14 19:42:57 UTC
moved from Incoming to Software Enhancements