- openldap-bugs - openldap.org

Re: (ITS#6664) Server control forwarding in back_meta and back_ldap
by masarati＠aero.polimi.it 08 Oct '10

08 Oct '10

> Note that the SSSVLV overlay can handle paged results locally too, thus > negating any need for back-ldap/back-meta to forward it to a remote > server. > Obviously for greatest generality, there needs to be a way to configure > which > set of controls to pass through, and which to process locally. (Much like > back-ldap's option to process the WhoAmI exop...) Right. With proxies the problem is twofold: a) clients request pr because they think they're talking to AD b) the proxy may need to use pr even if the client does not request it, because it knows it's talking to AD In (a), the issue could be handled the way sssvlv does, relieving the proxy from having to deal with server-side pr; this would be extremely beneficial, for example, for back-meta In (b), the proxy could be configured to use pr the way I mentioned above; in principle, the proxy could be so clever to avoid using pr, and simply accept to handle unrequested pr responses, but only if instructed to do so. Filtering what controls are passed thru should be easy, since both proxy backends always call ldap_back_controls_add()/meta_back_controls_add() to muck with request controls (usually to add proxied authorization and so); this function could easily strip or add pr if instructed to do so. p.

1 0

Re: (ITS#6665) back_ldap and back_meta chasing referrals authentication
by masarati＠aero.polimi.it 08 Oct '10

08 Oct '10

> Full_Name: Javier Sanz > Version: 2.4.17 > OS: Debian Linux 5.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.38.203.12) > > > back_ldap and back_meta should be able to do a non-anonymous bind to the > referrals returned by the external LDAP servers. > > This is a regression since 2.3, because the old directives "pseudorootdn" > and > "pseudorootpw" allowed specifying the binddn and password that would be > used to > chase the referrals, but their 2.4 replacements "idassert-bind" and > "idassert-authzFrom" do not allow that, so these binds are always done > anonymously. Back-ldap seems to work as expected if you set chase-referrals yes rebind-as-user yes idassert-bind bindmethod=simple binddn=<dn> credentials=<cred> mode=self and binddn <dn> with credentials <cred> exists on both the remote server and the one pointed to by the referral. With back-meta, it should work with the same parameters; however, I've checked and the specific code used to bind during searches does not set the rebind procedure correctly. I've fixed this in HEAD, please test. Thanks, p.

1 0

Re: (ITS#6664) Server control forwarding in back_meta and back_ldap
by hyc＠symas.com 08 Oct '10

08 Oct '10

masarati(a)aero.polimi.it wrote: >> Full_Name: Javier Sanz >> Version: 2.4.17 >> OS: Debian Linux 5.0 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (80.38.203.12) >> >> >> back_meta and back_ldap should forward server controls that clients use in >> their >> queries to the corresponding external LDAP servers. > > Both back-ldap and back-meta forward controls to the remote servers. > >> For example, the inhability to send controls to external servers currently >> causes that RFC2696 paged results control cannot be used, so it is >> impossible to >> retrieve more results for a query than the page size configured in the >> external >> server, which often is not a big number. > > As far as I can tell, back-ldap supports paged results correctly (just > tested with HEAD and 2.4.23 code). Back-meta does not, and likely will > never do. Please note that while all back-ldap needs to do is blindly > forward control request/response, back-meta would need to separately > handle requests server-side (i.e. when the client requests the control) > and client-side (i.e. when non LDAP-compliant remote servers return the > control while the client did not request it). In between, it would need > to return the page size requested by the client and store the (possibly > paged) response of each remote server. Not worth the effort. The > solution consists in increasing the page size returned by default by > non-LDAP compliant remote servers. > > Perhaps the problem could be split in two: > > 1) allow to configure per-target mandatory use of paged results, with a > specified page size; this means that search requests hitting a specific > target would always add the paged results control to the request, and > handle control responses accordingly. > > 2) handle server-side control response in an overlay that takes care of > storing search results and returning them as appropriate. This would > (maybe inefficiently) handle paged results regardless of the backend that > is actually handling a request. > > Even if only (1) is implemented, clients would no longer need to use pr > when talking to slapd, since back-meta would handle non-LDAP compliant > remote servers that return pr response when the control is not requested. > > I think this ITS should be closed (back-ldap and back-meta do forward > controls); maybe another ITS with a back-meta feature request to handle > non-LDAP compliant remote servers could be filed. Note that the SSSVLV overlay can handle paged results locally too, thus negating any need for back-ldap/back-meta to forward it to a remote server. Obviously for greatest generality, there needs to be a way to configure which set of controls to pass through, and which to process locally. (Much like back-ldap's option to process the WhoAmI exop...) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6664) Server control forwarding in back_meta and back_ldap
by masarati＠aero.polimi.it 08 Oct '10

08 Oct '10

> Full_Name: Javier Sanz > Version: 2.4.17 > OS: Debian Linux 5.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.38.203.12) > > > back_meta and back_ldap should forward server controls that clients use in > their > queries to the corresponding external LDAP servers. Both back-ldap and back-meta forward controls to the remote servers. > For example, the inhability to send controls to external servers currently > causes that RFC2696 paged results control cannot be used, so it is > impossible to > retrieve more results for a query than the page size configured in the > external > server, which often is not a big number. As far as I can tell, back-ldap supports paged results correctly (just tested with HEAD and 2.4.23 code). Back-meta does not, and likely will never do. Please note that while all back-ldap needs to do is blindly forward control request/response, back-meta would need to separately handle requests server-side (i.e. when the client requests the control) and client-side (i.e. when non LDAP-compliant remote servers return the control while the client did not request it). In between, it would need to return the page size requested by the client and store the (possibly paged) response of each remote server. Not worth the effort. The solution consists in increasing the page size returned by default by non-LDAP compliant remote servers. Perhaps the problem could be split in two: 1) allow to configure per-target mandatory use of paged results, with a specified page size; this means that search requests hitting a specific target would always add the paged results control to the request, and handle control responses accordingly. 2) handle server-side control response in an overlay that takes care of storing search results and returning them as appropriate. This would (maybe inefficiently) handle paged results regardless of the backend that is actually handling a request. Even if only (1) is implemented, clients would no longer need to use pr when talking to slapd, since back-meta would handle non-LDAP compliant remote servers that return pr response when the control is not requested. I think this ITS should be closed (back-ldap and back-meta do forward controls); maybe another ITS with a back-meta feature request to handle non-LDAP compliant remote servers could be filed. p.

1 0

Re: (ITS#6667) memberof infinite recursion on node rename
by masarati＠aero.polimi.it 08 Oct '10

08 Oct '10

Can you provide a minimal example that triggers the problem? You should boil it down to: - the slapd.conf or the contents of the cn=config database - the LDIF needed to populate the database - the operation that causes the problem (I presume it's a modify or a write operation, so you should be able to provide it in form of LDIF and main parameters, e.g. the identity that is performing the operation). Thanks, p.

1 0

Re: (ITS#6632) Core dump in test030 when using back-ldap
by masarati＠aero.polimi.it 08 Oct '10

08 Oct '10

Valgrind shows more issues possibly related to this ITS when SLAP_NO_SL_MALLOC is defined. When running test047, whoami results in conn=1013 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.3 conn=1013 op=1 WHOAMI ==11941== Thread 5: ==11941== Conditional jump or move depends on uninitialised value(s) ==11941== at 0x820B122: rwm_op_rollback (rwm.c:62) ==11941== by 0x820B518: rwm_op_cleanup (rwm.c:165) ==11941== by 0x809EC0F: slap_cleanup_play (result.c:436) ==11941== by 0x809F34B: send_ldap_response (result.c:621) ==11941== by 0x80A0035: slap_send_ldap_extended (result.c:802) ==11941== by 0x80C90BD: fe_extended (extended.c:237) ==11941== by 0x810E8FD: overlay_op_walk (backover.c:669) ==11941== by 0x810EAB2: over_op_func (backover.c:721) ==11941== by 0x810EC71: over_op_extended (backover.c:796) ==11941== by 0x80C8D95: do_extended (extended.c:177) ==11941== by 0x808AD29: connection_operation (connection.c:1109) ==11941== by 0x808B269: connection_read_thread (connection.c:1245) ==11941== by 0x8235884: ldap_int_thread_pool_wrapper (tpool.c:685) ==11941== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==11941== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==11941== ==11941== Conditional jump or move depends on uninitialised value(s) ==11941== at 0x820B13A: rwm_op_rollback (rwm.c:65) ==11941== by 0x820B518: rwm_op_cleanup (rwm.c:165) ==11941== by 0x809EC0F: slap_cleanup_play (result.c:436) ==11941== by 0x809F34B: send_ldap_response (result.c:621) ==11941== by 0x80A0035: slap_send_ldap_extended (result.c:802) ==11941== by 0x80C90BD: fe_extended (extended.c:237) ==11941== by 0x810E8FD: overlay_op_walk (backover.c:669) ==11941== by 0x810EAB2: over_op_func (backover.c:721) ==11941== by 0x810EC71: over_op_extended (backover.c:796) ==11941== by 0x80C8D95: do_extended (extended.c:177) ==11941== by 0x808AD29: connection_operation (connection.c:1109) ==11941== by 0x808B269: connection_read_thread (connection.c:1245) ==11941== by 0x8235884: ldap_int_thread_pool_wrapper (tpool.c:685) ==11941== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==11941== by 0xD42DBD: clone (in /lib/libc-2.5.so) conn=1013 op=1 RESULT oid= err=0 text= Possibly, although not directly, related leaks: ==11941== ==11941== 244 bytes in 4 blocks are definitely lost in loss record 10 of 11 ==11941== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==11941== by 0x826BB67: ber_memalloc_x (memory.c:226) ==11941== by 0x80F5229: slap_sl_malloc (sl_malloc.c:285) ==11941== by 0x826BB82: ber_memalloc_x (memory.c:229) ==11941== by 0x824C16E: ldap_dn2bv_x (getdn.c:3015) ==11941== by 0x80A53E2: dnPrettyNormal (dn.c:745) ==11941== by 0x820D4DC: rwm_exop_passwd (rwm.c:1048) ==11941== by 0x820D7C5: rwm_extended (rwm.c:1116) ==11941== by 0x810E87D: overlay_op_walk (backover.c:659) ==11941== by 0x810EAB2: over_op_func (backover.c:721) ==11941== by 0x810EC71: over_op_extended (backover.c:796) ==11941== by 0x80C8D95: do_extended (extended.c:177) ==11941== by 0x808AD29: connection_operation (connection.c:1109) ==11941== by 0x808B269: connection_read_thread (connection.c:1245) ==11941== by 0x8235884: ldap_int_thread_pool_wrapper (tpool.c:685) ==11941== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==11941== by 0xD42DBD: clone (in /lib/libc-2.5.so) Will look at this ASAP. p.

1 0

Re: (ITS#6666) Feature Request: Triggers implementation
by hyc＠symas.com 07 Oct '10

07 Oct '10

Hallvard B Furuseth wrote: > Maybe an overlay version of back-sock, with an overlay option > which says whether or not to wait for responses from the socket? Sure. Someone could easily start with e.g. chain.c or pbind.c and write an overlay wrapper for back-sock. Patches welcome. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6666) Feature Request: Triggers implementation
by h.b.furuseth＠usit.uio.no 07 Oct '10

07 Oct '10

Maybe an overlay version of back-sock, with an overlay option which says whether or not to wait for responses from the socket?

1 0

(ITS#6667) memberof infinite recursion on node rename
by miguelangel＠nbee.es 07 Oct '10

07 Oct '10

Full_Name: Miguel Angel Ajo Pelayo Version: 2.4.23 stable OS: Linux (Centos5) URL: Submission from: (NULL) (95.16.169.142) I detected that my (compiled from source) openldap crashes on node rename. I run gdb and detected an infinite (too big) recursion that seems to be related with the "memberof" overlay. This is the GDB / debug output: >>> dnNormalize: <cn=aaa aaavzadadfa,dc=nbee,dc=es> <<< dnNormalize: <cn=aaa aaavzadadfa,dc=nbee,dc=es> bdb_modrdn: new ndn=cn=aaa aaavzadadfa,dc=nbee,dc=es => bdb_dn2id("cn=aaa aaavzadadfa,dc=nbee,dc=es") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) => bdb_dn2id_delete 0x11: "cn=aaa aaavzadadf,dc=nbee,dc=es" <= bdb_dn2id_delete 0x11: 0 => bdb_dn2id_add 0x11: "cn=aaa aaavzadadfa,dc=nbee,dc=es" <= bdb_dn2id_add 0x11: 0 bdb_modify_internal: 0x00000011: cn=aaa aaavzadadfa,dc=nbee,dc=es oc_check_required entry (cn=aaa aaavzadadfa,dc=nbee,dc=es), objectClass "inetOrgPerson" oc_check_required entry (cn=aaa aaavzadadfa,dc=nbee,dc=es), objectClass "posixAccount" oc_check_allowed type "givenName" oc_check_allowed type "sn" oc_check_allowed type "gidNumber" oc_check_allowed type "uid" oc_check_allowed type "uidNumber" oc_check_allowed type "userPassword" oc_check_allowed type "loginShell" oc_check_allowed type "homeDirectory" oc_check_allowed type "objectClass" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "entryUUID" oc_check_allowed type "creatorsName" oc_check_allowed type "createTimestamp" oc_check_allowed type "cn" oc_check_allowed type "entryCSN" oc_check_allowed type "modifiersName" oc_check_allowed type "modifyTimestamp" => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => entry_encode(0x00000011): cn=aaa aaavzadadfa,dc=nbee,dc=es <= entry_encode(0x00000011): cn=aaa aaavzadadfa,dc=nbee,dc=es bdb_modrdn: rdn modified id=00000011 dn="cn=aaa aaavzadadf,dc=nbee,dc=es" send_ldap_result: conn=1007 op=2 p=3 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb79e7b90 (LWP 11613)] 0x080eaf7e in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_aux_chk_controls) at backover.c:713 713 db = *op->o_bd; #0 0x080eaf7e in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_aux_chk_controls) at backover.c:713 #1 0x080eb21c in over_aux_chk_controls (op=0xb79e680c, rs=0xb79e67d0) at backover.c:814 #2 0x0807bc38 in backend_check_restrictions (op=0xb79e680c, rs=0xb79e67d0, opdata=0x0) at backend.c:1036 #3 0x0806e1fa in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:334 #4 0x080eae42 in overlay_op_walk (op=0xb79e680c, rs=0xb79e67d0, which=op_search, oi=0x8304f40, on=0x0) at backover.c:669 #5 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #6 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #7 0x0806e3a3 in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:366 [.......] A LOT of recursion... #37385 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #37386 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #37387 0x0806e3a3 in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:366 #37388 0x080eae42 in overlay_op_walk (op=0xb79e680c, rs=0xb79e67d0, which=op_search, oi=0x8304f40, on=0x0) at backover.c:669 #37389 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #37390 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #37391 0x08163ee4 in memberof_isGroupOrMember (op=0x8370ce0, mci=0xb6fe4450) at memberof.c:288 ---Type <return> to continue, or q <return> to quit--- #37392 0x0816723b in memberof_res_modrdn (op=0x8370ce0, rs=0xb79e7134) at memberof.c:1451 #37393 0x0807e621 in slap_response_play (op=0x8370ce0, rs=0xb79e7134) at result.c:402 #37394 0x0807e7cc in send_ldap_response (op=0x8370ce0, rs=0xb79e7134) at result.c:476 #37395 0x0807f5a2 in slap_send_ldap_result (op=0x8370ce0, rs=0xb79e7134) at result.c:750 #37396 0x080fbca9 in bdb_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:789 #37397 0x0808bbb0 in fe_op_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:314 #37398 0x080eae42 in overlay_op_walk (op=0x8370ce0, rs=0xb79e7134, which=op_modrdn, oi=0x8304f40, on=0x0) at backover.c:669 #37399 0x080eaff7 in over_op_func (op=0x8370ce0, rs=0xb79e7134, which=op_modrdn) at backover.c:721 #37400 0x080eb10c in over_op_modrdn (op=0x8370ce0, rs=0xb79e7134) at backover.c:766 #37401 0x0808b513 in do_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:186 #37402 0x0806aed0 in connection_operation (ctx=0xb79e7220, arg_v=0x8370ce0) at connection.c:1109 #37403 0x0806b410 in connection_read_thread (ctx=0xb79e7220, argv=0xe) at connection.c:1245 #37404 0x081b5055 in ldap_int_thread_pool_wrapper (xpool=0x82d9e00) at tpool.c:685 #37405 0x00adf832 in start_thread () from /lib/libpthread.so.0 #37406 0x00220e0e in clone () from /lib/libc.so.6 Any idea of why could this be happening?

1 0

Re: (ITS#6666) Feature Request: Triggers implementation
by nick＠eurobjects.com 07 Oct '10

07 Oct '10

Sorry, I' m not a developer. I'm trying to find a solution from an administrator's point of view. How about doing something like: on log attr <attrname> notify <[ip]:[port]> which would send a "message" with the attr name, the old and the new value of the attribute to [ip]:[port]. Then, someone can set up a net listening process like netcat (nc) to read data and do whatever. Nick On 7/10/2010 5:32 πμ, Howard Chu wrote: > > Spawning processes is not thread safe. The solution you propose will > never be implemented. Alternative suggestions are welcome. >

1 0

Re: (ITS#6666) Feature Request: Triggers implementation
by hyc＠symas.com 06 Oct '10

06 Oct '10

nick(a)eurobjects.com wrote: > Full_Name: Nick Milas > Version: 2.3.43 > OS: CentOS 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (94.65.0.240) > > > Triggers in openldap is a much-desired feature. As mentioned in various places, > openldap community suggests using the accesslog overlay to log changes and then > use another process to listen to changes (e.g. back-perl) or back-sock (I saw > the example in the source tree), feasibly back-shell or even write one's own > overlay. The problem is that all those methods require low-level programming > (not to mention various incompatibilities with system components), which makes > them unusable by administrators, that is by those who mainly install and run > openldap and directories. As a result, I would suggest to slightly enhance > future versions by offering minimal trigger support over the accesslog overlay. > > > So I would suggest to support in slapd.conf a statement like: > "on log attr<attribute name> call<bash script>" (with obvious meaning). > > I consider this would allow the openldap average administrator to use particular > attributes as triggers to start scripts which in turn offer the advantage of > full access to script programming, which does not require low-level > programming. > > Spawning processes is not thread safe. The solution you propose will never be implemented. Alternative suggestions are welcome. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

memberof infinite recursion on node rename
by Miguel Angel 06 Oct '10

06 Oct '10

Hi there, I think I found a bug. I detected that my (compiled from source) openldap crashes on node rename. I run gdb and detected an infinite (too big) recursion that seems to be related with the "memberof" overlay. I'm not familiar with openldap sources, so I decided to post it here, and then try to help fixing it with your advice: This is the GDB / debug output: >>> dnNormalize: <cn=aaa aaavzadadfa,dc=nbee,dc=es> <<< dnNormalize: <cn=aaa aaavzadadfa,dc=nbee,dc=es> bdb_modrdn: new ndn=cn=aaa aaavzadadfa,dc=nbee,dc=es => bdb_dn2id("cn=aaa aaavzadadfa,dc=nbee,dc=es") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) => bdb_dn2id_delete 0x11: "cn=aaa aaavzadadf,dc=nbee,dc=es" <= bdb_dn2id_delete 0x11: 0 => bdb_dn2id_add 0x11: "cn=aaa aaavzadadfa,dc=nbee,dc=es" <= bdb_dn2id_add 0x11: 0 bdb_modify_internal: 0x00000011: cn=aaa aaavzadadfa,dc=nbee,dc=es oc_check_required entry (cn=aaa aaavzadadfa,dc=nbee,dc=es), objectClass "inetOrgPerson" oc_check_required entry (cn=aaa aaavzadadfa,dc=nbee,dc=es), objectClass "posixAccount" oc_check_allowed type "givenName" oc_check_allowed type "sn" oc_check_allowed type "gidNumber" oc_check_allowed type "uid" oc_check_allowed type "uidNumber" oc_check_allowed type "userPassword" oc_check_allowed type "loginShell" oc_check_allowed type "homeDirectory" oc_check_allowed type "objectClass" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "entryUUID" oc_check_allowed type "creatorsName" oc_check_allowed type "createTimestamp" oc_check_allowed type "cn" oc_check_allowed type "entryCSN" oc_check_allowed type "modifiersName" oc_check_allowed type "modifyTimestamp" => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(DELETE,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => key_change(ADD,11) <= key_change 0 => entry_encode(0x00000011): cn=aaa aaavzadadfa,dc=nbee,dc=es <= entry_encode(0x00000011): cn=aaa aaavzadadfa,dc=nbee,dc=es bdb_modrdn: rdn modified id=00000011 dn="cn=aaa aaavzadadf,dc=nbee,dc=es" send_ldap_result: conn=1007 op=2 p=3 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb79e7b90 (LWP 11613)] 0x080eaf7e in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_aux_chk_controls) at backover.c:713 713 db = *op->o_bd; #0 0x080eaf7e in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_aux_chk_controls) at backover.c:713 #1 0x080eb21c in over_aux_chk_controls (op=0xb79e680c, rs=0xb79e67d0) at backover.c:814 #2 0x0807bc38 in backend_check_restrictions (op=0xb79e680c, rs=0xb79e67d0, opdata=0x0) at backend.c:1036 #3 0x0806e1fa in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:334 #4 0x080eae42 in overlay_op_walk (op=0xb79e680c, rs=0xb79e67d0, which=op_search, oi=0x8304f40, on=0x0) at backover.c:669 #5 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #6 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #7 0x0806e3a3 in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:366 [.......] A LOT of recursion... #37385 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #37386 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #37387 0x0806e3a3 in fe_op_search (op=0xb79e680c, rs=0xb79e67d0) at search.c:366 #37388 0x080eae42 in overlay_op_walk (op=0xb79e680c, rs=0xb79e67d0, which=op_search, oi=0x8304f40, on=0x0) at backover.c:669 #37389 0x080eaff7 in over_op_func (op=0xb79e680c, rs=0xb79e67d0, which=op_search) at backover.c:721 #37390 0x080eb0a6 in over_op_search (op=0xb79e680c, rs=0xb79e67d0) at backover.c:748 #37391 0x08163ee4 in memberof_isGroupOrMember (op=0x8370ce0, mci=0xb6fe4450) at memberof.c:288 ---Type <return> to continue, or q <return> to quit--- #37392 0x0816723b in memberof_res_modrdn (op=0x8370ce0, rs=0xb79e7134) at memberof.c:1451 #37393 0x0807e621 in slap_response_play (op=0x8370ce0, rs=0xb79e7134) at result.c:402 #37394 0x0807e7cc in send_ldap_response (op=0x8370ce0, rs=0xb79e7134) at result.c:476 #37395 0x0807f5a2 in slap_send_ldap_result (op=0x8370ce0, rs=0xb79e7134) at result.c:750 #37396 0x080fbca9 in bdb_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:789 #37397 0x0808bbb0 in fe_op_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:314 #37398 0x080eae42 in overlay_op_walk (op=0x8370ce0, rs=0xb79e7134, which=op_modrdn, oi=0x8304f40, on=0x0) at backover.c:669 #37399 0x080eaff7 in over_op_func (op=0x8370ce0, rs=0xb79e7134, which=op_modrdn) at backover.c:721 #37400 0x080eb10c in over_op_modrdn (op=0x8370ce0, rs=0xb79e7134) at backover.c:766 #37401 0x0808b513 in do_modrdn (op=0x8370ce0, rs=0xb79e7134) at modrdn.c:186 #37402 0x0806aed0 in connection_operation (ctx=0xb79e7220, arg_v=0x8370ce0) at connection.c:1109 #37403 0x0806b410 in connection_read_thread (ctx=0xb79e7220, argv=0xe) at connection.c:1245 #37404 0x081b5055 in ldap_int_thread_pool_wrapper (xpool=0x82d9e00) at tpool.c:685 #37405 0x00adf832 in start_thread () from /lib/libpthread.so.0 #37406 0x00220e0e in clone () from /lib/libc.so.6 Any idea of why could this be happening? Thanks in advance, Miguel Angel Ajo Pelayo http://www.nbee.es +34 636 52 25 69 skype: ajoajoajo

2 1

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 06 Oct '10

06 Oct '10

masarati(a)aero.polimi.it wrote: >> Hey Pierangelo, >> >> I just noticed http://www.openldap.org/its/index.cgi?findid=6574 - this >> looks like it fixes the issue I mentioned in >> http://www.openldap.org/its/index.cgi?findid=6540? Is that assertion >> correct? > > I couldn't specifically look at your issue (apart from the simple fix to > allow cn=config to work). ITS#6574 should have nothing to do with your > issue, as it affects back-meta in a part that has no code commonality with > back-ldap, and slapo-chain is built on top of back-ldap. I apologize - it had occurred to me that since http://www.openldap.org/doc/admin24/backends.html#Metadirectory states that back-meta and back-ldap share a subset of code, and since the issue described in ITS#6574 appears to be *exactly* the same problem I'm seeing in ITS#6540, that they might have been one and the same. > I'm sorry I went back through this thread and got somehow lost; what's the > exact topic now? I infer (from followup #14) that there seems to be an > issue about chaining because slapo-chain seems not to rebind as expected. ITS#6540 had two parts: 1. The test script failed to identify a specific set of conditions in which slapo-chain would cause slapcat to fail and also prevent slapd from being restarted after slapo-chain was enabled. 2. The problem that the test script failed to detect with slapo-chain is directly related to the current problem: slapo-chain does not properly rebind as the appropriate user as set in the olcDbIDAssertBind attribute. Instead, it rebinds as 'anonymous' (an empty DN), which is of very little practical use, since unauthenticated anonymous users should not be allowed to modify anything. As a result, slapd kicks the referral back to the client instead of chasing it automatically, which completely defeats the purpose of using slapo-chain. > Could you isolate the problem in a minimal setup (slapd.conf or the > corresponding back-config's LDIF, a database and a simple operation that > can be performed with ldapmodify/ldappasswd or so) to clearly reproduce > the issue? > > Thanks, p. > The configuration and test operations below should show exactly what's going on, but first, allow me to describe the process in a nutshell: 1. The client binds to the slave and issues a modification request 2. The slave creates the referral and tries to chase it automatically on the client's behalf to the upstream master using slapo-chain 3. The automatic referral chasing fails because the DN is not passed through and the slave erroneously rebinds to the master as anonymous (an empty DN) instead of the identity it's configured to assert, as set by the olcDbIDAssertBind attribute. 4. Because the automatic referral chasing fails, the slave kicks back the referral to the client, stating that the client "is not logged in" to the master and that "modifications require authentication". 5. When the client provides credentials for the referral (manual referral chasing), the rest of the operation works as expected (updates made on master, which then cascades to the slaves). The following LDIFs and sample operations exemplify the problem; please let me know if this example suffices, or if you need a more complete reference or further clarification: ################################################# # CONFIGURATION # ################################################# ### back-config base entry on slave (abbreviated) dn: cn=config objectClass: olcGlobal cn: config olcConfigDir: /etc/ldap/slapd.d olcReadOnly: FALSE olcReverseLookup: FALSE olcTLSCACertificateFile: /etc/ldap/ssl/certs/cacert.pem olcTLSCertificateFile: /etc/ldap/ssl/certs/openldap.cert.pem olcTLSCertificateKeyFile: /etc/ldap/ssl/keys/openldap.key.pem olcAuthzPolicy: none olcLogLevel: stats sync olcPasswordHash: {SSHA}SUPERSECRET olcServerID: 1 ldap://master1.example.com olcServerID: 2 ldap://slave1.example.com ### back-config modules entry dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb.la olcModuleLoad: {1}autogroup.la olcModuleLoad: {2}syncprov.la olcModuleLoad: {3}back_ldap.la ### back-config chain overlay entry dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain ### back-config chain database dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: ldap://master1.example.com olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=com" credentials=SECRET mode=self ################################################# # SIMPLE OPERATIONAL EXAMPLE # ################################################# ### NOTE: This example uses ldapvi, but results are identical to ldapmodify, etc. ### NOTE: The client binds initially to the slave as the admin here, but results are identical to scenarios in which the client binds as a regular user ### Attempting to modify 'displayColor' attribute belonging to entry 'uid=ryans,ou=Users,dc=example,dc=com' root@slave1:~# ldapvi -h localhost --bind=simple -D cn=admin,dc=example,dc=com -w `cat /etc/ldap.secret` --discover 159 entries read add: 0, rename: 0, modify: 1, delete: 0 Action? [yYqQvVebB*rsf+?] y Received referral to ldap://master1.example.com/uid=ryans,ou=Users,dc=example,dc=com. You are not logged in to ldap://master1.example.com:389 yet. Type '!' or 'y' to do so. Rebind? [y!nB*qQ?] y --- Login Type M-h for help on key bindings. Filter or DN: cn=admin,dc=example,dc=com Password: *********** Bound as cn=admin,dc=example,dc=com. Done. ################################################# # LOGS FOR OPERATIONAL EXAMPLE # ################################################# ### Logs on slave showing referral was correctly generated (err=10) Oct 5 10:27:04 slave1 slapd[30408]: conn=44 fd=41 ACCEPT from IP=127.0.0.1:34118 (IP=0.0.0.0:389) Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=0 STARTTLS Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=0 RESULT oid= err=0 text= Oct 5 10:27:04 slave1 slapd[30408]: conn=44 fd=41 TLS established tls_ssf=128 ssf=128 Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=1 BIND dn="cn=admin,dc=example,dc=com" method=128 Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=1 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0 Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=1 RESULT tag=97 err=0 text= Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SRCH attr=+ * Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 ENTRY dn="" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="dc=example,dc=com" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="cn=admin,dc=example,dc=com" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="ou=users,dc=example,dc=com" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="ou=groups,dc=example,dc=com" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="uid=ryans,ou=users,dc=example,dc=com" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="cn=ryans,ou=groups,dc=example,dc=com" Oct 5 10:27:04 slave1 slapd[30408]: conn=44 op=3 SEARCH RESULT tag=101 err=0 nentries=159 text= Oct 5 10:27:07 slave1 slapd[30408]: conn=44 op=4 MOD dn="uid=ryans,ou=Users,dc=example,dc=com" Oct 5 10:27:07 slave1 slapd[30408]: conn=44 op=4 MOD attr=displayColor Oct 5 10:27:07 slave1 slapd[30408]: conn=44 op=4 RESULT tag=103 err=10 text= ### Logs on master showing that when the slave tried to chase the referral, it erroneously bound as anonymous ### NOTE: slave1.example.com = 10.0.1.196 Oct 5 10:27:07 master1 slapd[8794]: conn=402475 fd=273 ACCEPT from IP=10.0.1.196:43376 (IP=0.0.0.0:389) Oct 5 10:27:07 master1 slapd[8794]: conn=402475 op=0 BIND dn="" method=128 Oct 5 10:27:07 master1 slapd[8794]: conn=402475 op=0 RESULT tag=97 err=0 text= Oct 5 10:27:07 master1 slapd[8794]: conn=402475 op=1 MOD dn="uid=ryans,ou=Users,dc=example,dc=com" Oct 5 10:27:08 master1 slapd[8794]: conn=402475 op=1 MOD attr=displayColor Oct 5 10:27:08 master1 slapd[8794]: conn=402475 op=1 RESULT tag=103 err=8 text=modifications require authentication Oct 5 10:27:08 master1 slapd[8794]: conn=402475 op=2 UNBIND Oct 5 10:27:08 master1 slapd[8794]: conn=402475 fd=273 closed Oct 5 10:27:08 master1 slapd[8794]: conn=402476 fd=273 ACCEPT from IP=10.0.1.196:43377 (IP=0.0.0.0:389) If there are any details not shown that you'd like, or any clarification you require, or if there's anything at all you need to help facilitate the investigation, please let me know and I'll do my best to accommodate. Thanks! -Ryan

1 0

(ITS#6666) Feature Request: Triggers implementation
by nick＠eurobjects.com 06 Oct '10

06 Oct '10

Full_Name: Nick Milas Version: 2.3.43 OS: CentOS 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.65.0.240) Triggers in openldap is a much-desired feature. As mentioned in various places, openldap community suggests using the accesslog overlay to log changes and then use another process to listen to changes (e.g. back-perl) or back-sock (I saw the example in the source tree), feasibly back-shell or even write one's own overlay. The problem is that all those methods require low-level programming (not to mention various incompatibilities with system components), which makes them unusable by administrators, that is by those who mainly install and run openldap and directories. As a result, I would suggest to slightly enhance future versions by offering minimal trigger support over the accesslog overlay. So I would suggest to support in slapd.conf a statement like: "on log attr <attribute name> call <bash script>" (with obvious meaning). I consider this would allow the openldap average administrator to use particular attributes as triggers to start scripts which in turn offer the advantage of full access to script programming, which does not require low-level programming.

1 0

Re: FW: (ITS#5941) Problem when stacking rwm and translucent overlays together
by wdh＠vasco.com 06 Oct '10

06 Oct '10

--=-J3E4Om04oCzTAxqDTGlw Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit > In the meanwhile, you can try to use an instance of back-ldap as the > translucent local storage, and place slapo-rwm on the database of the > remote server that acts as local. I haven't tested it, so there might be > minor issues, but I don't expect anything like this one. Thanks for the input. This is also not an option because the remote server is in fact an Active Directory. Which in this case I can't alter. I will try to create 2 slapd process - One which will do the translucent proxy stuff, running on a non standard port - one which will have a back-ldap to this non standard port and doing there the rewrites. Thanks for helping me with this issue. --=-J3E4Om04oCzTAxqDTGlw Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3"> </HEAD> <BODY> <PRE> > In the meanwhile, you can try to use an instance of back-ldap as the > translucent local storage, and place slapo-rwm on the database of the > remote server that acts as local.  I haven't tested it, so there might be > minor issues, but I don't expect anything like this one. Thanks for the input. This is also not an option because the remote server is in fact an Active Directory. Which in this case I can't alter. I will try to create 2 slapd process - One which will do the translucent proxy stuff, running on a non standard port - one which will have a back-ldap to this non standard port and doing there the rewrites. Thanks for helping me with this issue. </PRE> </BODY> </HTML> --=-J3E4Om04oCzTAxqDTGlw--

1 0

Re: FW: (ITS#5941) Problem when stacking rwm and translucent overlays together
by masarati＠aero.polimi.it 06 Oct '10

06 Oct '10

> I installed the latest version currently available 2.4.23 > The same bug still exists in this version. > > So I can for sure say this is not related to ITS#6070 > > Since this is a major loss of functionality I would kindly ask someone to > h= > ave a deeper look at this. I confirm it is related to ITS#6070; only, that ITS could be fixed (read: worked around) differently. I don't think this qualifies as a "major loss of functionality" for the vast majority of the users of OpenLDAP. Solving this issue the right way (and few others) would require to advance OpenLDAP at least to 2.5 or 3.0, because a significant portion of the ABI would need to change, so do not expect to see it solved any soon. In the meanwhile, you can try to use an instance of back-ldap as the translucent local storage, and place slapo-rwm on the database of the remote server that acts as local. I haven't tested it, so there might be minor issues, but I don't expect anything like this one. p.

1 0

FW: (ITS#5941) Problem when stacking rwm and translucent overlays together
by wdh＠vasco.com 05 Oct '10

05 Oct '10

I installed the latest version currently available 2.4.23 The same bug still exists in this version. So I can for sure say this is not related to ITS#6070 Since this is a major loss of functionality I would kindly ask someone to h= ave a deeper look at this. Thanks Wouter=

1 0

Re: (ITS#5941) Problem when stacking rwm and translucent overlays together
by wdh＠vasco.com 05 Oct '10

05 Oct '10

--=-pjbfbkt+SDCV4FzF9Ohv Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit I'm hitting this bug also in Debian Lenny. Is this bug already fixed? It prevents me from implementing our OpenLDAP server. Thanks Wouter --=-pjbfbkt+SDCV4FzF9Ohv Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3"> </HEAD> <BODY> I'm hitting this bug also in Debian Lenny. Is this bug already fixed? It prevents me from implementing our OpenLDAP server. Thanks Wouter </BODY> </HTML> --=-pjbfbkt+SDCV4FzF9Ohv--

1 0

(ITS#6665) back_ldap and back_meta chasing referrals authentication
by jsceballos＠gmail.com 05 Oct '10

05 Oct '10

Full_Name: Javier Sanz Version: 2.4.17 OS: Debian Linux 5.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.38.203.12) back_ldap and back_meta should be able to do a non-anonymous bind to the referrals returned by the external LDAP servers. This is a regression since 2.3, because the old directives "pseudorootdn" and "pseudorootpw" allowed specifying the binddn and password that would be used to chase the referrals, but their 2.4 replacements "idassert-bind" and "idassert-authzFrom" do not allow that, so these binds are always done anonymously.

1 0

(ITS#6664) Server control forwarding in back_meta and back_ldap
by jsceballos＠gmail.com 05 Oct '10

05 Oct '10

Full_Name: Javier Sanz Version: 2.4.17 OS: Debian Linux 5.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.38.203.12) back_meta and back_ldap should forward server controls that clients use in their queries to the corresponding external LDAP servers. For example, the inhability to send controls to external servers currently causes that RFC2696 paged results control cannot be used, so it is impossible to retrieve more results for a query than the page size configured in the external server, which often is not a big number.

1 0

Re: (ITS#6647) Overlay sssvlv is always loaded
by clem.oudot＠gmail.com 05 Oct '10

05 Oct '10

--=-sj86jeXTHEFBrrKIl07g Content-Type: text/plain; charset=utf-8 Content-ID: <1286271588.1952.3.camel@Nokia-N900-51-1> Content-Transfer-Encoding: 8bit ----- Message d'origine ----- > > > Please try this (nearly blind) patch > > > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.pat…> > > > > and report through the ITS. Thanks, p. > > I note that I have messed things up a bit in cleanup; however, this > should not affect the testing of the functionality, except if you delete > the overlay from the configuration using back-config. If the patch works > fine, I'll fix that part. > Hi, sorry for this late reply. I tried the patch on 2.4.23 source code, the second hunk was not working, so I deleted it to apply the patch. I am not using cn=config anyway. After recompiling with your patch and --enable-overlays, all works fine: a search with sss extention returns success (and fails if the control is critical). So I think you can commit the code! Thanks, Clément. --=-sj86jeXTHEFBrrKIl07g Content-Type: text/html; charset=utf-8 Content-ID: <1286271588.1952.5.camel@Nokia-N900-51-1> Content-Transfer-Encoding: 8bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="generator" content="Osso Notes"> <title></title></head> <body> ----- Message d'origine ----- > > > Please try this (nearly blind) patch > > > > <<a href="ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.pat…">ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.pat…</a>; > > > > and report through the ITS.  Thanks, p. > > I note that I have messed things up a bit in cleanup; however, this > should not affect the testing of the functionality, except if you delete > the overlay from the configuration using back-config.  If the patch works > fine, I'll fix that part. > Hi, sorry for this late reply. I tried the patch on 2.4.23 source code, the second hunk was not working, so I deleted it to apply the patch. I am not using cn=config anyway. After recompiling with your patch and --enable-overlays, all works fine: a search with sss extention returns success (and fails if the control is critical). So I think you can commit the code! Thanks, Clément. </body> </html> --=-sj86jeXTHEFBrrKIl07g--

1 0

(ITS#6663) refint not altering last attribute on delete
by knewell＠math.arizona.edu 04 Oct '10

04 Oct '10

Full_Name: Karl Newell Version: 2.4.21 OS: Ubuntu 10.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.196.224.235) refint does not alter the value of an attribute to refint_nothing when the last "member" of a group is deleted. refint is working when the dn of a member is modified. slapd.conf: loglevel 16383 ... moduleload refint ... overlay refint refint_attributes member uniqueMember seeAlso refint_nothing cn=Manager,dc=math,dc=arizona,dc=edu ... ldap.log (what I believe to be the relevant entries): ... Oct 4 14:12:03 vm-ldap slapd[8744]: refint_search_cb <cn=LDAP Admins,ou=Groups,dc=math,dc=arizona,dc=edu> Oct 4 14:12:03 vm-ldap slapd[8744]: refint_search_cb: uniqueMember: uid=atb,ou=Users,dc=math,dc=arizona,dc=edu (#1) Oct 4 14:12:03 vm-ldap slapd[8744]: send_ldap_result: conn=-1 op=0 p=0 Oct 4 14:12:03 vm-ldap slapd[8744]: send_ldap_result: err=0 matched="" text="" Oct 4 14:12:03 vm-ldap slapd[8744]: refint_search_cb <NOTHING> Oct 4 14:12:03 vm-ldap slapd[8744]: hdb_modify: cn=LDAP Admins,ou=Groups,dc=math,dc=arizona,dc=edu Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_dn2entry("cn=ldap admins,ou=groups,dc=math,dc=arizona,dc=edu") Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_modify_internal: 0x00000008: cn=LDAP Admins,ou=Groups,dc=math,dc=arizona,dc=edu Oct 4 14:12:03 vm-ldap slapd[8744]: <= acl_access_allowed: granted to database root Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_modify_internal: delete uniqueMember Oct 4 14:12:03 vm-ldap slapd[8744]: dnMatch 0#012#011"uid=atb,ou=users,dc=math,dc=arizona,dc=edu"#012#011"uid=atb,ou=users,dc=math,dc=arizona,dc=edu" Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_modify_internal: replace modifiersName Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_modify_internal: delete uniqueMember Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_modify_internal: 16 modify/delete: uniqueMember: no such attribute Oct 4 14:12:03 vm-ldap slapd[8744]: hdb_modify: modify failed (16) Oct 4 14:12:03 vm-ldap slapd[8744]: send_ldap_result: conn=-1 op=0 p=0 Oct 4 14:12:03 vm-ldap slapd[8744]: send_ldap_result: err=16 matched="" text="modify/delete: uniqueMember: no such attribute" Oct 4 14:12:03 vm-ldap slapd[8744]: refint_repair: dependent modify failed: 16 ...

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by quanah＠zimbra.com 30 Sep '10

30 Sep '10

--On Thursday, September 30, 2010 11:14 AM +0000 masarati(a)aero.polimi.it wrote: > There's no mention of overlays; I was wondering whether or not it could be > related to some adverse interaction, e.g. with sssvlv, which has some > paged-results specific code. Can you also post on overlays either global > or specific to "olcDatabase={2}hdb"? There are no overlays being used. ;) As I said, a very vanilla config. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: ITS#6661 (Was: FW: (6661))
by masarati＠aero.polimi.it 30 Sep '10

30 Sep '10

Should be fine now. The whole thing originated from the fact that be_rootdn_bind() was passed a NULL SlapReply* without handling results accordingly. Thanks, p. > Yes it is fixed, > > But in your fix, only the rootpw password works. If we have the rootdn > also as a dn stored inside the ldap tree then openldap does not tries to > bind to the dn of the tree if the rootpw is incorrect > > if we use the same code segment of bind.cpp written for back-bdb which is: > > /* allow noauth binds */ > switch ( be_rootdn_bind( op, NULL ) ) { > case LDAP_SUCCESS: > /* frontend will send result */ > return rs->sr_err; > default: > break; > } > And the rootpw is not matched, then slapd will continue to search the ldap > tree and if it finds a dn and its userPassword matches, then it > authenticates. If an appropriate dn / password is not found in the tree, > then it throughs the invalid credentials error. > > Maybe the bind-dbd way is more correct? > >

1 0

RE: ITS#6661 (Was: FW: (6661))
by gtzanetis＠pylones.gr 30 Sep '10

30 Sep '10

Yes it is fixed, But in your fix, only the rootpw password works. If we have the rootdn also= as a dn stored inside the ldap tree then openldap does not tries to bind t= o the dn of the tree if the rootpw is incorrect if we use the same code segment of bind.cpp written for back-bdb which is: /* allow noauth binds */ switch ( be_rootdn_bind( op, NULL ) ) { case LDAP_SUCCESS: /* frontend will send result */ return rs->sr_err; default: break; } And the rootpw is not matched, then slapd will continue to search the ldap = tree and if it finds a dn and its userPassword matches, then it authenticat= es. If an appropriate dn / password is not found in the tree, then it throu= ghs the invalid credentials error. Maybe the bind-dbd way is more correct?

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs