openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#7591) back-meta modify operation not sending result to client
by hyc＠symas.com 26 Jul '13

26 Jul '13

jorge.perez.burgos(a)ericsson.com wrote: > Hi, > > At the end, meta_back_op_result() will map inside the error returned by ldap_modify_ext to LDAP_OTHER, since we don't call it with LDAP_BACK_SENDERR, nothing is sent. Since the error is not LDAP_UNAVAILABLE there will be no retries. I think this happens too in add and delete. This explanation makes no sense, since meta_back_op_result is being called with LDAP_BACK_SENDRESULT, which is SENDOK|SENDERR. The bug is definitely a problem, I can reproduce it running test036 repeatedly on my laptop. Typically the test hangs within 5-10 iterations. > BR > > -----Original Message----- > From: Pierangelo Masarati [mailto:pierangelo.masarati@polimi.it] > Sent: lunes, 20 de mayo de 2013 21:41 > To: Jorge Perez Burgos > Cc: openldap-its(a)openldap.org > Subject: Re: (ITS#7591) back-meta modify operation not sending result to client > > On 05/15/2013 08:57 AM, jorge.perez.burgos(a)ericsson.com wrote: >> kludge fix for the problem >> >> --- servers/slapd/back-meta/modify.c 2012-07-31 18:39:26.000000000 +0200 >> +++ servers/slapd/back-meta/modify.c 2013-05-14 12:45:39.273333000 +0200 >> @@ -176,6 +176,7 @@ >> } >> modv[ i ] = 0; >> >> + rs->sr_type = -1; >> retry:; >> ctrls = op->o_ctrls; >> rc = meta_back_controls_add( op, rs, mc, candidate, &ctrls ); @@ >> -198,6 +200,10 @@ >> } >> >> cleanup:; >> + if (rs->sr_type != REP_RESULT) { >> + send_ldap_error(op, rs, LDAP_OTHER, "connection problem trying to reach the other node"); >> + } >> + >> (void)mi->mi_ldap_extra->controls_free( op, rs, &ctrls ); >> >> if ( mdn.bv_val != op->o_req_dn.bv_val ) { > > Thanks for the feedback; I am under the impression that a result should have been returned by meta_back_op_result(). Before applying the suggested fix, I would like to understand whether that function was called and in case why it did not send a result. > > p. > -- -- 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#7615) NetBSD sem_open limited to 14 characters
by hyc＠symas.com 26 Jul '13

26 Jul '13

hyc(a)symas.com wrote: > Greg(a)Akua.com wrote: >> Full_Name: Greg Kerr >> Version: 2.4.35 >> OS: NetBSD & FreeBSD >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (50.88.130.68) >> >> >> MDB is not usable on NetBSD because mdb.c has >> >> sprintf(env->me_txns->mti_wmname, "/MDBw%s", hexbuf); >> >> To create the semaphore name. >> >> This results in a 21 character name which is beyond the 14 allowed per "man >> sem_open" > > That's unfortunate. In Linux this limit is 251 characters. Seems you'd need to > use the btoa algorithm to safely fit a hash into this size limit. > > Pretty sure we've tested successfully on FreeBSD and MacOSX already, so > apparently they don't suffer from this same limit. mdb.master has been patched to use the btoa algorithm, which reduces our semaphore name length down to 15 chars. On NetBSD we additionally truncate the last to bring it down to 14. >> "less than 14 characters in length not including the terminating null >> character." >> >> I will make a local patch ... and maybe it's a NetBSD bug - or at least the >> package maintainers ... I will report to him. It's a NetBSD kernel limitation, which I verified here: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/uipc_sem.c?rev=1.40&conten… Seems like a stupid limit, but whatever. Also the doc wording is inaccurate, the name can actually be *up to* 14 chars. "Less than 14" to most English speakers means the length must be *less than* 14. I.e., 13 or shorter. But in fact 14 characters are allowed. If you're contacting the NetBSD maintainers already, please tell them their manpage is incorrect. -- -- 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#7649) Feature request: numSubordinates attribute
by michael＠stroeder.com 26 Jul '13

26 Jul '13

On Fri, 26 Jul 2013 15:03:41 GMT hyc(a)symas.com wrote > Need to think about this some more. While it's true that the back-hdb/mdb > backends already have this information and can easily provide it, it > introduces new security concerns that sysadmins would have to be aware of. > I.e., clients could use numsubordinates to discover the existence of entries > they are not permitted to access. Which means sysadmins would need to add new > ACLs specifically for controlling access to numsubordinates. > > If we just add the feature, and sysadmins aren't aware it was added, then > they have a security hole. True, but not really a new security consideration for an admin. We already have 'hasSubordinates' anyway. And for whatever new operational attribute introduced in former times the admin was considered responsible to restrict access by appropriate ACLs. I also find such an attribute to be very useful in some use-cases. Another aspect is how searches like (numSubordinates>=1) can be efficiently handled, e.g. in cases where most entries will have numSubordinates=0. Yes, I admit I use it for count-like searches where using no-op search control is too expensive. Ciao, Michael.

1 0

Re: (ITS#7649) Feature request: numSubordinates attribute
by ghenry＠OpenLDAP.org 26 Jul '13

26 Jul '13

> Need to think about this some more. While it's true that the back-hdb/mdb > backends already have this information and can easily provide it, it > introduces new security concerns that sysadmins would have to be aware of. > I.e., clients could use numsubordinates to discover the existence of entries > they are not permitted to access. Which means sysadmins would need to add > new ACLs specifically for controlling access to numsubordinates. > > If we just add the feature, and sysadmins aren't aware it was added, then > they have a security hole. That's very true. If it's an operational attribute wouldn't normal ACLs apply? For example if you are only permitted to see "self" in ou=Users, then you shouldn't be able to request numSubordinates on ou=Users or if you do you only see 1. Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk Did you see our API? http://www.surevoip.co.uk/api

1 0

Re: (ITS#7649) Feature request: numSubordinates attribute
by hyc＠symas.com 26 Jul '13

26 Jul '13

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > Dear all, > > It would be great if we supported a numSubordinates attribute so you can request > a count of the number of entries say at a base of > ou=suretec.hosted.surevoip.co.uk,ou=Contacts,dc=surevoip,dc=co,dc=uk rather than > retrieve them all and count them up. I know there is a contrib noopsrch overlay > that others are using. > > The only reference I can see that other directories has is based on this: > > http://tools.ietf.org/html/draft-ietf-boreham-numsubordinates-01 Need to think about this some more. While it's true that the back-hdb/mdb backends already have this information and can easily provide it, it introduces new security concerns that sysadmins would have to be aware of. I.e., clients could use numsubordinates to discover the existence of entries they are not permitted to access. Which means sysadmins would need to add new ACLs specifically for controlling access to numsubordinates. If we just add the feature, and sysadmins aren't aware it was added, then they have a security hole. -- -- 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

(ITS#7649) Feature request: numSubordinates attribute
by ghenry＠OpenLDAP.org 26 Jul '13

26 Jul '13

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Dear all, It would be great if we supported a numSubordinates attribute so you can request a count of the number of entries say at a base of ou=suretec.hosted.surevoip.co.uk,ou=Contacts,dc=surevoip,dc=co,dc=uk rather than retrieve them all and count them up. I know there is a contrib noopsrch overlay that others are using. The only reference I can see that other directories has is based on this: http://tools.ietf.org/html/draft-ietf-boreham-numsubordinates-01 Thanks, Gavin.

1 0

(ITS#7648) undefined symbol: ldap_x_utf8s_to_wcs
by msquaredm＠yahoo.com 25 Jul '13

25 Jul '13

Full_Name: Mike Version: 2.4.35 OS: Cent0s v6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.51.198.154) Hi, I've compiled v2.4.35 with the smbk5pwd overlay. When I change my password the openldap terminates with the message: /usr/sbin/slapd: symbol lookup error: /usr/lib64/openldap/smbk5pwd-2.4.so.2: undefined symbol: ldap_x_utf8s_to_wcs Thanks for any help. Mike

1 0

(ITS#7645) various TLSProtocolMin issues
by mgaupp＠googlemail.com 24 Jul '13

24 Jul '13

Full_Name: Manuel Gaupp Version: 2.4.35 OS: CentOS 6.3 URL: Submission from: (NULL) (79.234.218.31) This topic was originally discussed in http://www.openldap.org/lists/openldap-technical/201307/msg00133.html 1.) the TLSProtocolMin parameter is not documented, but it should be - at least in slapd.conf/slapd-config and ldap.conf (there is an example in the original ITS #5655) 2.) the TLSProtocolMin functionality should be extended for TLS 1.1 and TLS 1.2 (see http://www.openldap.org/lists/openldap-technical/201307/msg00138.html) 3.) ldap.conf already accepts correctly formatted TLSProtocolMin values (e.g. "3.1") whereas slapd.conf doesn't (has to be given as an integer, e.g. "769"); I think servers/slapd/bconfig.c should be changed to use ldap_int_tls_config for this option (as mentioned in the FIXME comment of config_tls_config).

1 0

Re: (ITS#7643) MDB_cmp_func not properly documented
by hyc＠symas.com 23 Jul '13

23 Jul '13

vissermc(a)gmail.com wrote: > Full_Name: Michiel Visser > Version: 2.4.35 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.159.211.22) > > > The MDB documentation must specify what is expected of MDB_cmp_func. > I assume it must return -1,0,1 depending on the order, similar to ansi compare > functions, but it is not trivial, nor all will know. The mdb_cmp() description already describes the return values. Users of the library are expected to be able to associate related concepts. -- -- 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#7644) inverted MDB_SET_RANGE desired
by hyc＠symas.com 23 Jul '13

23 Jul '13

vissermc(a)gmail.com wrote: > Full_Name: Michiel Visser > Version: 2.4.35 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.159.211.22) > > > Feature request: > MDB_SET_RANGE is an important option for me (I'm implementing a generic triple > store on top of MDB). But I also desire some additions: > 1) let's call it MDB_SET_RANGE_INV: find key equal of smaller. In theory I could > also apply an inverted compare function, but this makes it counter-intuitive > ('bigger' actually implying 'smaller'). And I understand I can also use > SET_RANGE, followed by a cursor-previous-traversal, but it would require extra > logic to check whether the key is already equal, which brings me to my second > point: Extra logic will be required anyway, whether inside liblmdb or in your application. In this case I don't see value in making the library bigger to handle this. > 2) a way to see whether the returned key is equal (to the supplied key), to > avoid another call to get/cursor_get, or avoid a manual key compare. The mdb_cursor_get() function signature is what it is, there's nowhere to return any other parameters. How would you propose to indicate this to the caller? -- -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs