February 2012 - 389-devel - Fedora Mailing-Lists

Please review: [389 Project] #51: memory leaks in 389-ds-base-1.2.8.2-1.el5?

by Noriko Hosoi

https://fedorahosted.org/389/ticket/51 https://fedorahosted.org/389/attachment/ticket/51/0001-Trac-Ticket-51-mem... Fix description: Ran valgrind with the MMR+SASL servers and fixed leaks found in the test. [plugin/replication/repl5_connection.c] conn_connect could have overridden conn->ld without releasing it. This patch releases it if necessary. [slapd/dn.c] If DN normalization fails in slapi_sdn_get_dn, this patch releases the locally strdup'ed string. [slapd/modify.c, modutil.c] DN syntax attribute value is found in mods, it was normalized and replaced in slapi_mods_insert_at. It leaked the pre- noralized value. Instead, this patch normalizes mods in do_modify and frees it when the modify is done. [slapd/operation.c] modrdn_newsuperior_address.sdn was not release when the modrdn operaton is done. This patch adds the release code.

12 years, 2 months

1
0
0 / 0

Please review: coverity 12488 Resource leak In attr_index_config()

by Rich Megginson

12 years, 2 months

2
1
0 / 0

Please review: Ticket #281 - TLS not working with latest openldap

by Rich Megginson

https://fedorahosted.org/389/ticket/281 https://fedorahosted.org/389/attachment/ticket/281/0001-Ticket-281-TLS-no...

12 years, 2 months

1
0
0 / 0

Please review: Ticket #280 - extensible binary filters do not work

by Rich Megginson

https://fedorahosted.org/389/ticket/280 https://fedorahosted.org/389/attachment/ticket/280/0001-Ticket-280-extens...

12 years, 2 months

1
0
0 / 0

Please review: Ticket #279 - filter normalization does not use matching rules

by Rich Megginson

https://fedorahosted.org/389/ticket/279 https://fedorahosted.org/389/attachment/ticket/279/0001-Ticket-279-filter...

12 years, 2 months

1
0
0 / 0

Please review: Ticket #278 - Schema replication update failed: Invalid syntax

by Rich Megginson

https://fedorahosted.org/389/ticket/278 https://fedorahosted.org/389/attachment/ticket/278/0001-Ticket-278-Schema...

12 years, 2 months

1
0
0 / 0

Please review: Ticket #277 - cannot set repl referrals or state

by Rich Megginson

https://fedorahosted.org/389/ticket/277 https://fedorahosted.org/389/attachment/ticket/277/0001-Ticket-277-cannot...

12 years, 2 months

1
0
0 / 0

Please review: [389 Project] #275: Invalid read reported by valgrind

by Noriko Hosoi

https://fedorahosted.org/389/ticket/275 https://fedorahosted.org/389/attachment/ticket/275/0001-Trac-Ticket-275-I... Fix description: Since the matching rule type could be normalized and the original string could be freed in filter_normalize_ext, the type needs to have a duplicated string (bitwise.c, plugin_mr.c). Filter_ava functions and filter_sub functions in the syntax plugins need to check if the passed pblock is NULL or not before accessing it.

12 years, 2 months

1
0
0 / 0

please review ticket #39 - Account Policy doesn't work when authenticating through the PAM plugin

by Mark Reynolds

https://fedorahosted.org/389/attachment/ticket/39 https://fedorahosted.org/389/attachment/ticket/39/0001-Ticket-39-Account-... Thanks, Mark

12 years, 2 months

1
0
0 / 0

PAM plugin vs post op processing. New return code proposal...

by Mark Reynolds

Hi Everyone, There is an issue with the PAM plugin, that when it performs a successful bind we actually return error 1 to plugins_call_func(), which essentially causes the abort of the all plugin processing: the rest of pre-op, the backend call, and all of post-op. PAM has completed the bind and already returned the result, so it returns 1 to stop the DS from doing the rest of bind op. Makes sense... However, with the Account Policy plugin, when tracking the "last bind time", binding thru PAM won't update the entry, even though the bind was successful. This is because the successful PAM bind essentially aborted all the pre-op and post-op plugins. I feel that we should still call the post op plugins in this scenario. The pre-op plugins should still be aborted, because the operation was already completed - there's nothing to reject at that point. So to get around plugins like this, I am proposing a new plugin pre-op return code(either use 1, or -2). This return code implies that the operation was fully completed, and that we should also process the post op plugins - but do not send the operation to the backend. So to the recap, the new return code says the operation was fully completed by the plugin, but we still want to process just the post-op plugins. I know this will impact documentation, there might be unforeseen issues, and this is also a rare situation(only PAM plugin seems to behave like this). Saying that, I still think its the valid solution to this type of problem. It could also allow future plugins for be more versatile/robust. Please let me know your thoughts. Thanks, Mark

12 years, 2 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-devel February 2012