Re: (ITS#6845) sortvals oddities - with more information
by hyc＠symas.com
Andrew Elble wrote:
> Howard Chu<hyc(a)symas.com> writes:
>
>>> It would seem that attr_merge() (in attr.c) should have something like this:
>>>
>>> if ( *a == NULL ) {
>>> *a = attr_alloc( desc );
>>> if (desc->ad_type->sat_flags& SLAP_AT_SORTED_VAL) {
>>> (*a)->a_flags |= SLAP_ATTR_SORTED_VALS;
>>> }
>>> } else {
>>
>> This is now fixed in HEAD in value.c.
>
> Tested, bad behavior still persists. The call path I've observed
> is as follows:
>
> T@5 : | | | | |>bdb_modify_internal
> T@5 : | | | | | |>modify_add_values
> T@5 : | | | | | | |>attr_merge
> T@5 : | | | | | | | |>attr_alloc
>
> ordered_value_add() doesn't seem to be involved (I can provide the
> entire trace if necessary)
Thanks, my mistake. Fixed now in HEAD attr.c (redundant code removed from add.c)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 9 months
(ITS#6848) wait timeout for slapd startup
by quanah＠OpenLDAP.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.24
OS: NA
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.111.45.108)
When LDAP is used as a dependency for other software during the init process (as
a kerberos backend, for example), the fact that slapd exits with success prior
to it being ready to accept connections can cause problems for the later
services that depend on it. It would be useful to have an (optional) flag "-w
<seconds>" that if provided, would have slapd wait up until <seconds> amount of
time has passed for the daemon to fully initialize. If it fails to initialize
and be ready to accept connections by the end of the time period (when
specified), slapd should exit with a new unique error code. This would allow
for avoiding the startup problem. An example of this (and a terrible solution)
can be found in:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589915
Debian implemented a broken solution for this, but it is a general issue for
anyone who has dependencies on slapd being ready.
12 years, 9 months
Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by subbarao＠computer.org
> On 02/28/2011 04:57 AM, Howard Chu wrote:
>> Right, no problem. I've run your updated script against HEAD and see no
>> errors, nor is there a duplicate result sent for the Bind operation.
>
> That's a good datapoint. I'll look into building HEAD on my system and
> validate that the duplicate result messages are gone.
I was able to build HEAD pretty quickly (much quicker than I've been
able to in the past :-) ), and was able to validate that the test succeeds.
-Kartik
12 years, 9 months
Re: (ITS#6845) sortvals oddities - with more information
by aweits＠rit.edu
Howard Chu <hyc(a)symas.com> writes:
>> It would seem that attr_merge() (in attr.c) should have something like this:
>>
>> if ( *a == NULL ) {
>> *a = attr_alloc( desc );
>> if (desc->ad_type->sat_flags& SLAP_AT_SORTED_VAL) {
>> (*a)->a_flags |= SLAP_ATTR_SORTED_VALS;
>> }
>> } else {
>
> This is now fixed in HEAD in value.c.
Tested, bad behavior still persists. The call path I've observed
is as follows:
T@5 : | | | | | >bdb_modify_internal
T@5 : | | | | | | >modify_add_values
T@5 : | | | | | | | >attr_merge
T@5 : | | | | | | | | >attr_alloc
ordered_value_add() doesn't seem to be involved (I can provide the
entire trace if necessary)
>> Further pursuing the issue, I started to focus on the index deletion
>> code that was changed as a part of ITS#5183. Specifically, the
>> portion of code within bdb_modify_internal() (in back-bdb/modify.c)
>> that is commented:
>>
>> /* Move deleted values to end of array */
>>
>> This code modifies save_attrs, which is actually apparently a pointer
>> to memory that resides within the cache. If a deadlock occurs, these
>> changes are not reverted, thereby corrupting the entry in the cache. I
>> replaced this code with the pre-ITS#5183 code and I am no longer able
>> to 'break' the object and insert duplicate member/memberUids.
>
> This is now fixed in HEAD.
Looks good, thanks.
--
Andrew W. Elble
aweits(a)discipline.rit.edu
Infrastructure Engineer, Communications Technical Lead
Rochester Institute of Technology
PGP: BFAD 8461 4CCF DC95 DA2C B0EB 965B 082E 863E C912
CONFIDENTIALITY NOTE: The information transmitted, including
attachments, is intended only for the person(s) or entity to which it
is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of,
or taking of any action in reliance upon this information by persons
or entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender and destroy any
copies of this information.
12 years, 9 months
Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by subbarao＠computer.org
On 02/28/2011 04:57 AM, Howard Chu wrote:
> Kartik Subbarao wrote:
>> I'd like to add one clarification to this message. I named the attached
>> test script that illustrates the two RESULT messages problem
>> test099-ppolicy-update, per Howard's previous advice not to duplicate
>> existing names. But I just realized that this script relies on the same
>> data files that I previously submitted (slapd-ppolicy.conf,
>> ppolicy.ldif) so when running this script please ensure that those files
>> are in place.
>
> Right, no problem. I've run your updated script against HEAD and see no
> errors, nor is there a duplicate result sent for the Bind operation.
That's a good datapoint. I'll look into building HEAD on my system and
validate that the duplicate result messages are gone.
Alternatively, is there an easy way for you to run the script against
2.4.23 on your side? If so, and if you can reproduce the error that I
got with 2.4.23, that would be a solid confirmation that the bug has
since been fixed. Don't worry about it though if it would be too much of
a hassle -- I appreciate all your help with this.
Thanks,
-Kartik
12 years, 9 months
Re: (ITS#6817) idassert-bind with SASL issues
by hyc＠symas.com
masarati(a)aero.polimi.it wrote:
> Full_Name: Pierangelo Masarati
> Version: HEAD/re24
> OS: irrelevant
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (2.40.14.92)
> Submitted by: ando
>
>
> When idassert-bind is configured to use SASL bind, an "authcID" needs to be
> provided, while the "binddn" is not needed. However, if a "binddn" is not
> provided as well, in some cases the proxiedAuthz control may be used
> incorrectly. The need to configure the "binddn" is not documented, so this ITS
> is minimally addressed by documenting this requirement.
I tripped over this change while investigating #6711. Adding this requirement
is certainly not the right solution; SASL Binds ordinarily don't require a
BindDN and requiring it here just makes things confusing.
Also with the fixes that I made for #6711 I don't believe the issue exists any
more. Please describe the conditions where the problem occurs.
> If the "binddn" is provided, everything works as expected, with the only minor
> issue that the DN of the user as it is known to back-meta may not match the
> actual identity the "authcID" assumed on the remote server. The "right" way to
> address this problem consists in performing a "WhoAmI" (RFC 4532) right after
> the bind, or better use a "authorization identity control" (RFC 3829) along with
> the bind operation. Both approaches should be implemented, but they should not
> be used unless explicitly requested.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 9 months
Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by hyc＠symas.com
Kartik Subbarao wrote:
> I'd like to add one clarification to this message. I named the attached
> test script that illustrates the two RESULT messages problem
> test099-ppolicy-update, per Howard's previous advice not to duplicate
> existing names. But I just realized that this script relies on the same
> data files that I previously submitted (slapd-ppolicy.conf,
> ppolicy.ldif) so when running this script please ensure that those files
> are in place.
Right, no problem. I've run your updated script against HEAD and see no
errors, nor is there a duplicate result sent for the Bind operation.
There's a config error because back-ldap in HEAD now always requires the
binddn to be set in the idassert-bind directive. I have a feeling that this
new requirement is bogus, and I just patched your script to set binddn="" to
get around it for the moment.
> Thanks,
>
> -Kartik
>
> On 02/02/2011 11:50 AM, Kartik Subbarao wrote:
>>>> Another problem is that bind operations to the consumer server start to
>> >> return two result messages -- one with the error code of the chained
>> >> operation, and one with the error code of the bind operation.
>>
>> I'm continuing to see this problem, even after I fix the acl-bind and
>> the 'manage' ACL configuration. See the attached for an updated test
>> script that illustrates the problem -- I've added a bind with an
>> incorrect password which should return 49, but instead is returning 0 to
>> the client.
>>
>> The last line of output from the test script is:
>>
>> ldap bind operation returned 0, expected 49
>>
>> For the relevant operation in slapd.2.log, I see the following:
>>
>> conn=1003 op=0 RESULT tag=103 err=0 text=
>> [...]
>> conn=1003 op=0 RESULT tag=97 err=49 text=
>>
>> slapd is returning two RESULT messages for the BIND operation. Error 0
>> seems to be from the successful chained modification of the
>> pwdFailureTime attribute, and Error 49 seems to be for the incorrect
>> password.
>>
>> -Kartik
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 9 months
Re: (ITS#6845) sortvals oddities - with more information
by hyc＠symas.com
aweits(a)rit.edu wrote:
> Full_Name: Andrew Elble
> Version: 2.4.24 / CVS Head
> OS: Solaris / MacOS
> URL:
> Submission from: (NULL) (129.21.6.207)
>
Thanks for the detailed report.
>
> We are using sortvals on both member and memberUid. We have been
> seeing duplicate member/memberUid attributes on some objects that have
> been modified (as well as a lack of sorting on those attributes). It
> seemed that there was a correlation between modifies to objects that
> experienced deadlocks and the objects that had duplicate
> member/memberUid attributes on them. We put the seqmod overlay in
> place - and this reduced the number of occurrences of the issue but
> did not eliminate them.
>
> Upon further investigation, I discovered that it was possible to
> bypass the sorting behavior if the object was not created with an
> instance of the attribute with sorting enabled as a part of it.
>
> It would seem that attr_merge() (in attr.c) should have something like this:
>
> if ( *a == NULL ) {
> *a = attr_alloc( desc );
> if (desc->ad_type->sat_flags& SLAP_AT_SORTED_VAL) {
> (*a)->a_flags |= SLAP_ATTR_SORTED_VALS;
> }
> } else {
This is now fixed in HEAD in value.c.
> Further pursuing the issue, I started to focus on the index deletion
> code that was changed as a part of ITS#5183. Specifically, the
> portion of code within bdb_modify_internal() (in back-bdb/modify.c)
> that is commented:
>
> /* Move deleted values to end of array */
>
> This code modifies save_attrs, which is actually apparently a pointer
> to memory that resides within the cache. If a deadlock occurs, these
> changes are not reverted, thereby corrupting the entry in the cache. I
> replaced this code with the pre-ITS#5183 code and I am no longer able
> to 'break' the object and insert duplicate member/memberUids.
This is now fixed in HEAD.
> I also found it surprising that the call to bdb_idl_cache_del() in
> bdb_idl_delete_key() in back-bdb/idl.c occurred prior to any calls to
> the database?
I see what you mean. I don't think this causes any harm though.
> I can answer any questions about the specifics of the environment
> in which where we are seeing this - it is a somewhat difficult problem to
> reproduce outside of our production environment. I'm not terribly
> familiar with the code - I'm looking to see if I have collected enough
> data here to open an ITS to have this fixed. (or if I'm just way off base)
>
>
> Thanks,
>
> Andy
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 9 months
(ITS#6847) slapd segmentation fault
by dkastens＠uos.de
Full_Name: Dirk Kastens
Version: 2.4.24
OS: Red Hat Enterprise Linux Server release 5.6 (kernel 2.6.18-238.1.1.el5xen)
URL:
Submission from: (NULL) (2001:638:508:3d0:74e8:28f7:184a:4cdf)
I updated our openldap master and two replica servers to 2.4.24 (self-compiled)
last week. Saturday morning, both replicas crashed at the same time with a
segementation fault:
kernel: slapd[2150]: segfault at 0000000000000059 rip 00000000004fb9e7 rsp
0000000042f9e630 error 4
kernel: slapd[9451]: segfault at 0000000000000059 rip 00000000004fb9e7 rsp
000000004563f630 error 4
Running slapd with valgrind --tool=memcheck --leak-check=full gives:
==31485== LEAK SUMMARY:
==31485== definitely lost: 0 bytes in 0 blocks
==31485== indirectly lost: 0 bytes in 0 blocks
==31485== possibly lost: 110,162 bytes in 4,698 blocks
==31485== still reachable: 6,942,591 bytes in 26,974 blocks
==31485== suppressed: 0 bytes in 0 blocks
==31485== Reachable blocks (those to which a pointer was found) are not shown.
==31485== To see them, rerun with: --leak-check=full --show-reachable=yes
==31485==
==31485== For counts of detected and suppressed errors, rerun with: -v
==31485== ERROR SUMMARY: 256 errors from 256 contexts (suppressed: 16 from 7)
==31485== Warning: set address range perms: large range [0xba78000, 0x1fa7a000)
(defined)
==31485== Warning: set address range perms: large range [0xba78000, 0x1fa7a000)
(noaccess)
==31485== Warning: invalid file descriptor -1 in syscall read()
12 years, 9 months
