openldap-bugs September 2024

openldap-bugs@openldap.org

1 participants
69 discussions

[Issue 10261] New: draft-behera-ldap-password-policy - evolution pwdAccountDisabled
by openldap-its＠openldap.org 01 Oct '24

01 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10261 Issue ID: 10261 Summary: draft-behera-ldap-password-policy - evolution pwdAccountDisabled Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- Hello, For information, I tried to send a mail at: draft-behera-ldap-password-policy(a)ietf.org first, but I get a: Recipient address rejected: User unknown I'd like to propose an evolution for the current version of draft-behera-ldap-password-policy. Indeed, in the specification, there is the notion of locked or blocked account, with the presence of pwdAccountLockedTime, preventing users from authenticating. However: * any account with sufficient privileges can modify the userPassword * when he does so, the pwdAccountLockedTime is removed This behaviour is advisable most of the time. But sometimes we need a more restrictive policy. The goal of this evolution is to propose an alternate behaviour where the "disabling attribute" is never removed unless asked explicitely, and where userPassword cannot be modified until the "disabling attribute" is present. This attribute could be named pwdAccountDisabled. Here is the proposed evolution: 4.1.1. Password Validity Policy ... A password cannot be used to authenticate while the corresponding account has been disabled. 4.2.8. Disabled account A password cannot be changed while the password owner has been disabled. While doing so, the LDAP directory should send a Constraint violation (19) error code with additional info: Account is disabled. 5.3.12. pwdAccountDisabled This attribute holds the time that the user's account was disabled. A disabled account means that the password may no longer be used to authenticate and none can change the userPassword until it is disabled. ( 1.3.6.1.4.1.42.2.27.8.1.33 NAME 'pwdAccountDisabled' DESC 'The time an user account was disabled' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE directoryOperation ) Thanks in advance for your consideration. Of course, it is opened to discussion, and maybe can I help a little for the implementation. Regards, -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10205] New: SSL handshake blocks forever in async mode if server unaccessible
by openldap-its＠openldap.org 26 Sep '24

26 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=10205 Issue ID: 10205 Summary: SSL handshake blocks forever in async mode if server unaccessible Product: OpenLDAP Version: 2.5.17 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: regtube(a)hotmail.com Target Milestone: --- When ldaps:// scheme is used to connect to currently unaccessible server with LDAP_OPT_CONNECT_ASYNC and LDAP_OPT_NETWORK_TIMEOUT options set, it blocks forever on SSL_connect. Here is a trace: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP winserv.test.net:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.56.2:636 ldap_pvt_connect: fd: 3 tm: 30 async: -1 ldap_ndelay_on: 3 attempting to connect: connect errno: 115 ldap_int_poll: fd: 3 tm: 0 ldap_err2string [2024-04-25 15:41:27.112] [error] [:1] bind(): Connecting (X) [2024-04-25 15:41:27.112] [error] [:1] err: -18 ldap_sasl_bind ldap_send_initial_request ldap_int_poll: fd: 3 tm: 0 ldap_is_sock_ready: 3 ldap_ndelay_off: 3 TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello Looks like it happens because non-blocking mode is cleared from the socket (ldap_ndelay_off) after the first poll for write, and non-blocking mode is never restored before attempt to do tls connect, because of the check that assumes that non-blocking mode has already been set for async mode: if ( !async ) { /* if async, this has already been set */ ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); } while in fact it was cleared. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10229] New: ldap_result, when invoked with MSG_RECEIVED and a timeout value set to 0 (polling), does not return all available messages until it is called again
by openldap-its＠openldap.org 26 Sep '24

26 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=10229 Issue ID: 10229 Summary: ldap_result, when invoked with MSG_RECEIVED and a timeout value set to 0 (polling), does not return all available messages until it is called again Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- The issue is noticeable when ldap_result is used by the proxy back-ends. It has not affected back-meta behavior, because when a first call is unsuccessful, it retries with a small timeout. back-asyncmeta will also usually call it twice on the same connection from different threads, although this is not a desired behavior. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 8611] Option to disable SSL renegotiation entirely
by openldap-its＠openldap.org 24 Sep '24

24 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8611 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |--- Summary|Option to block SSL |Option to disable SSL |renegotation after X |renegotiation entirely |attempts | --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Likely not needed for OpenLDAP, option would be to disable renegotiation entirely. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8491] slapdelete test needed
by openldap-its＠openldap.org 24 Sep '24

24 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8491 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8491] slapdelete test needed
by openldap-its＠openldap.org 24 Sep '24

24 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8491 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Target Milestone|2.7.0 |--- Resolution|--- |FIXED --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- already covered by slapmodify test007 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8890] adapt to 64-bit time_t on systems with 32-bit long
by openldap-its＠openldap.org 20 Sep '24

20 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8890 --- Comment #18 from tg(a)debian.org <tg(a)debian.org> --- On Sat, 21 Sep 2024, tg(a)debian.org wrote: >AIUI, this should likely be something like: … make that… +- keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); ++ keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long long) ); + keys[0].bv_len = snprintf(keys[0].bv_val, +- LDAP_PVT_INTTYPE_CHARS(long), ++ LDAP_PVT_INTTYPE_CHARS(long long), +- "%ld", slap_get_time()); ++ "%lld", (long long)slap_get_time()); … of course. (It’s 03:04 in the night, and re-reading those comments from above was not effortless.) bye, //mirabilos -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8890] adapt to 64-bit time_t on systems with 32-bit long
by openldap-its＠openldap.org 20 Sep '24

20 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8890 --- Comment #17 from tg(a)debian.org <tg(a)debian.org> --- On Sat, 21 Sep 2024, openldap-its(a)openldap.org wrote: >https://bugs.openldap.org/show_bug.cgi?id=8890 >I didn't understand Howard's comment ('the unconditional use of "long long" […] Looking at it *again*, with some years of distance, I *think* I now see what Howard’s barely comprehensible and rather rude comments were meant to point out. I did not see it at that time because ⓐ I was trying, and, as a nōn-English-native speaker, failing to puzzle out what he was saying, and ⓑ the OpenLDAP code’s use of abstractions here has massively reduced its legibility. + keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); + keys[0].bv_len = snprintf(keys[0].bv_val, + LDAP_PVT_INTTYPE_CHARS(long), +- "%ld", slap_get_time()); ++ "%lld", (long long)slap_get_time()); I think the first line of that is the point of critique. On repeat reading, it looks like it tries to figure out how many bytes are needed to represent a long, then allocates a buffer sized by this. As I correctly pointed out, this is a separate issue. However, Howard rejected both the immediate fix of printing wrong data RIGHT NOW (and likely truncating that at some point in the future) and this follow-up bug to address that truncation. AIUI, this should likely be something like: +- keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); ++ keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long long) ); + keys[0].bv_len = snprintf(keys[0].bv_val, + LDAP_PVT_INTTYPE_CHARS(long), +- "%ld", slap_get_time()); ++ "%lld", (long long)slap_get_time()); Of course, someone who actually knows wth LDAP_PVT_INTTYPE_CHARS is needs to ensure that it DTRT for an argument of “long long” first. bye, //mirabilos -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8890] adapt to 64-bit time_t on systems with 32-bit long
by openldap-its＠openldap.org 20 Sep '24

20 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8890 --- Comment #16 from Ryan Tandy <ryan(a)openldap.org> --- Debian and Ubuntu have both switched their remaining 32-bit architectures, except for i686, to 64-bit time_t. The change is in Ubuntu 24.04 (already released) and Debian 13/trixie (not yet released). Steve Langasek committed this distro patch: https://salsa.debian.org/openldap-team/openldap/-/blob/2a8f9240b9b6fd577d91… It's mostly the same as what was previously proposed in this ITS (changing %ld format specifiers to %lld), and unfortunately contains the same smbk5pwd bug that was already commented on. I didn't understand Howard's comment ('the unconditional use of "long long" instead of "long" will break on machines where "long long" is not 64 bits'). My understanding is C specifies "long long" to be at least 64 bits, and I'm not aware of any existing systems (yet) where "long long" is 128 bits - is it more of a futureproofing concern? Casting to long long and formatting with %lld seems to be the generally accepted solution in the broader community. If that's not acceptable, maybe scripting configure to generate a PRI_TIME_T format specifier? Steve's patch comment mentions an assertion failure in test046-dds on 32-bit ARM: servers/slapd/overlays/dds.c:422: dds_op_add: Assertion `bv.bv_len < sizeof( ttlbuf )' failed. I have not reproduced it myself (I don't have ARM hardware, and it isn't happening for me on x86). I note that the assertion ttl <= DDS_RF2589_MAX_TTL just above did not fail; but that does not rule out corruption of either the 64-bit value (could be negative) or the 32-bit quantity read by snprintf. I haven't figured out what actually happened here, but it's irritating me. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7981] Feature request: Crypt scheme in pwdPolicy
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=7981 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- We can't simply add this to the pwdPolicy objectclass since that is a standardized class. Also the values of crypt schemes are server specific, not standardized at all. A solution for us would be to define an OpenLDAP-specific subclass of the pwdPolicy class, and add whatever we need to in there and use it going forward. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2024