- openldap-bugs - openldap.org

Re: ITS#7518
by hyc＠symas.com 23 Apr '13

23 Apr '13

Matthew.Monaco(a)colorado.edu wrote: > commit c3411fb breaks building, reverting on OPENLDAP_REL_ENG_2_4 allows me to build > > were updated files omitted from the nss-pam-ldapd directory? Yes, it looks like it. Updated files now pushed to git master, thanks for the report. -- -- 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#7518
by Matthew.Monaco＠colorado.edu 23 Apr '13

23 Apr '13

commit c3411fb breaks building, reverting on OPENLDAP_REL_ENG_2_4 allows me to build were updated files omitted from the nss-pam-ldapd directory?

1 0

Re: (ITS#7576) olcLogFile does not work on Ubuntu 12.04
by quanah＠zimbra.com 18 Apr '13

18 Apr '13

--On Tuesday, April 16, 2013 5:06 PM +0000 hvnsweeting(a)gmail.com wrote: > Full_Name: Nguyen Viet Hung > Version: 2.4.28 > OS: Ubuntu 12.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (123.16.114.114) > > > I tried this directive on Ubuntu but it does not work. > Someone on openldap IRC said that > "olclogfile is only used on windows, because it lacks syslog" > > If he is right, please do change OpenLDAP document to make this less > confusing. Thanks Incorrect. Please read the slapd-config(5) man page. There is no issue using the logfile on linux. If you have questions on how to create one, please follow up with the openldap-technical list. This ITS will be closed. I would generally note that on linux setting the olcLogfile is not necessary, but if you must catch the stderr messages, you may which to do so. I would also note the version of OpenLDAP you are using is quite ancient. You'd be better served to upgrade to a current release. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7576) olcLogFile does not work on Ubuntu 12.04
by hvnsweeting＠gmail.com 16 Apr '13

16 Apr '13

Full_Name: Nguyen Viet Hung Version: 2.4.28 OS: Ubuntu 12.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.16.114.114) I tried this directive on Ubuntu but it does not work. Someone on openldap IRC said that "olclogfile is only used on windows, because it lacks syslog" If he is right, please do change OpenLDAP document to make this less confusing. Thanks

1 0

Re: (ITS#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by claude.brisson＠gmail.com 16 Apr '13

16 Apr '13

Ok, I understand, now. I totally overlooked the definition of MDB_NEXT_MULTIPLE, which I believed was here to return all the duplicate of the next key. Really sorry about all that noise. You may be interested in keeping the following little change from my patch, though: @@ -4377,6 +4377,8 @@ mdb_cursor_next(MDB_cursor *mc, MDB_val *key, MDB_val *data, MDB_cursor_op op) rc = mdb_cursor_first(&mc->mc_xcursor->mx_cursor, data, NULL); if (rc != MDB_SUCCESS) return rc; + } else if (mc->mc_db->md_flags & MDB_DUPSORT) { + mc->mc_xcursor->mx_cursor.mc_flags &= ~C_INITIALIZED; } } mdb_cursor_next should invalidate mx_cursor when there is no duplicate data for the current key. It's maybe useless if we are sure that we won't ever rely on this flag thereafter, but it's certainly safer. Regards, Claude On Mon, 15 Apr 2013 13:42:40 -0700 Howard Chu <hyc(a)symas.com> wrote: > claude.brisson(a)gmail.com wrote: > > On Mon, 15 Apr 2013 20:01:01 GMT > > hyc(a)symas.com wrote: > > > >> Your patch changes the meaning of these operations. > >> GET_MULTIPLE/NEXT_MULTIPLE is *only* for duplicate data and already > >> documented as such. > > > > The documentation in the header never states that MULTIPLE > > operations should *fail* on singletons. One could expect that the > > sentence "Return all the duplicate data items at the current cursor > > position" means that singletons will *also* be returned, without > > having to resort to a second call in case of failure. > > > >> Your patch makes them return non-duplicate data. This is a > >> fundamental change in an established behavior. A complete break, > >> actually; it will return data that doesn't match the key that the > >> client requested. It is completely wrong. > > > > I'm sorry if it broke something and made you loose your time, I was > > trying to help here. But the only change is to return singletons > > instead of MDB_NOTFOUND - the data will always match the key. > > No. This is in your patch: > > @@ -4803,7 +4806,7 @@ mdb_cursor_get(MDB_cursor *mc, MDB_val *key, > MDB_val *data, if (!(mc->mc_flags & C_INITIALIZED)) > rc = mdb_cursor_first(mc, key, data); > else > - rc = mdb_cursor_next(mc, key, data, > MDB_NEXT_DUP); > + rc = mdb_cursor_next(mc, key, data, > MDB_NEXT_NODUP); if (rc == MDB_SUCCESS) { > if (mc->mc_xcursor->mx_cursor.mc_flags & > C_INITIALIZED) { MDB_cursor *mx; > > So you've made it return non-matching data. > > > Maybe I missed something, here. But I wonder why the client code > > should at any point *expect* truly duplicate data. > > That is the sole purpose of these options. > > Re-read the description: > > MDB_GET_MULTIPLE, /**< Return all the duplicate data items > at the current > cursor position. Only for > #MDB_DUPFIXED */ > > If the current cursor position is a singleton, then you already have > its data if you positioned the cursor using (&key, &data) so there is > no need to make any further calls anyway. >

1 0

Re: (ITS#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by hyc＠symas.com 15 Apr '13

15 Apr '13

claude.brisson(a)gmail.com wrote: > On Mon, 15 Apr 2013 20:01:01 GMT > hyc(a)symas.com wrote: > >> Your patch changes the meaning of these operations. >> GET_MULTIPLE/NEXT_MULTIPLE is *only* for duplicate data and already >> documented as such. > > The documentation in the header never states that MULTIPLE operations > should *fail* on singletons. One could expect that the sentence "Return > all the duplicate data items at the current cursor position" means > that singletons will *also* be returned, without having to resort to a > second call in case of failure. > >> Your patch makes them return non-duplicate data. This is a >> fundamental change in an established behavior. A complete break, >> actually; it will return data that doesn't match the key that the >> client requested. It is completely wrong. > > I'm sorry if it broke something and made you loose your time, I was > trying to help here. But the only change is to return singletons > instead of MDB_NOTFOUND - the data will always match the key. No. This is in your patch: @@ -4803,7 +4806,7 @@ mdb_cursor_get(MDB_cursor *mc, MDB_val *key, MDB_val *data, if (!(mc->mc_flags & C_INITIALIZED)) rc = mdb_cursor_first(mc, key, data); else - rc = mdb_cursor_next(mc, key, data, MDB_NEXT_DUP); + rc = mdb_cursor_next(mc, key, data, MDB_NEXT_NODUP); if (rc == MDB_SUCCESS) { if (mc->mc_xcursor->mx_cursor.mc_flags & C_INITIALIZED) { MDB_cursor *mx; So you've made it return non-matching data. > Maybe I missed something, here. But I wonder why the client code should > at any point *expect* truly duplicate data. That is the sole purpose of these options. Re-read the description: MDB_GET_MULTIPLE, /**< Return all the duplicate data items at the current cursor position. Only for #MDB_DUPFIXED */ If the current cursor position is a singleton, then you already have its data if you positioned the cursor using (&key, &data) so there is no need to make any further calls anyway. -- -- 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#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by claude.brisson＠gmail.com 15 Apr '13

15 Apr '13

On Mon, 15 Apr 2013 20:01:01 GMT hyc(a)symas.com wrote: > Your patch changes the meaning of these operations. > GET_MULTIPLE/NEXT_MULTIPLE is *only* for duplicate data and already > documented as such. The documentation in the header never states that MULTIPLE operations should *fail* on singletons. One could expect that the sentence "Return all the duplicate data items at the current cursor position" means that singletons will *also* be returned, without having to resort to a second call in case of failure. > Your patch makes them return non-duplicate data. This is a > fundamental change in an established behavior. A complete break, > actually; it will return data that doesn't match the key that the > client requested. It is completely wrong. I'm sorry if it broke something and made you loose your time, I was trying to help here. But the only change is to return singletons instead of MDB_NOTFOUND - the data will always match the key. Maybe I missed something, here. But I wonder why the client code should at any point *expect* truly duplicate data. Regards, Claude

1 0

Re: (ITS#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by hyc＠symas.com 15 Apr '13

15 Apr '13

Claude Brisson wrote: > So it means the following: with the current code, when the client code > wants to optimize transfers with GET_MULTIPLE/NEXT_MULTIPLE, it has to > fall back to standard GET/NEXT whenever it encounters MDB_NOTFOUND. > Whereas the patch assumes that GET_MULTIPLE/NEXT_MULTIPLE will not > depend on the number of records. > > IMHO, the current behavior is a bit cumbersome. Would it be that > complex to update the client code? Your patch changes the meaning of these operations. GET_MULTIPLE/NEXT_MULTIPLE is *only* for duplicate data and already documented as such. Your patch makes them return non-duplicate data. This is a fundamental change in an established behavior. A complete break, actually; it will return data that doesn't match the key that the client requested. It is completely wrong. > > Claude > > On Sun, 14 Apr 2013 23:56:41 GMT > hyc(a)symas.com wrote: > >> hyc(a)symas.com wrote: >>> claude.brisson(a)gmail.com wrote: >>>> Full_Name: Claude Brisson >>>> Version: HEAD >>>> OS: linux 64 >>>> URL: >>>> ftp://ftp.openldap.org/incoming/0001-fix-MDB_GET_MULTIPLE-and-MDB_NEXT_MULT… >>>> Submission from: (NULL) (84.103.74.130) >>>> >>>> >>>> In a db with MDB_DUPSORT flag, when there is only one DUP data for >>>> a key, F_DUPDATA is not set for this key, and there is no >>>> sub-cursor. >>>> >>>> In this case, the current behaviour of MDB_GET_MULTIPLE and >>>> MDB_NEXT_MULTIPLE is broken because they make the assumption that >>>> there is always a sub-cursor for DUP data, which is only true for >>>> keys with more than one DUP data. >>>> >>>> This patch address this specific issue. >>> >>> Something's wrong with this patch, it breaks >>> MDB_GET_MULTIPLE/NEXT_MULTIPLE usage in slapd. Need to investigate >>> further. >>> >> The original code is correct. GET_MULTIPLE/NEXT_MULTIPLE are only >> valid when there actually are duplicate records. MDB_NEXT_MULTIPLE is >> essentially just a shortcut for calling MDB_NEXT_DUP in a loop. If >> there are no dups, then MDB_NEXT_DUP (and MDB_NEXT_MULTIPLE) return >> MDB_NOTFOUND. >> >> This patch was in mdb.master but has now been reverted. Closing this >> ITS. >> > > -- -- 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#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by claude.brisson＠gmail.com 15 Apr '13

15 Apr '13

So it means the following: with the current code, when the client code wants to optimize transfers with GET_MULTIPLE/NEXT_MULTIPLE, it has to fall back to standard GET/NEXT whenever it encounters MDB_NOTFOUND. Whereas the patch assumes that GET_MULTIPLE/NEXT_MULTIPLE will not depend on the number of records. IMHO, the current behavior is a bit cumbersome. Would it be that complex to update the client code? Claude On Sun, 14 Apr 2013 23:56:41 GMT hyc(a)symas.com wrote: > hyc(a)symas.com wrote: > > claude.brisson(a)gmail.com wrote: > >> Full_Name: Claude Brisson > >> Version: HEAD > >> OS: linux 64 > >> URL: > >> ftp://ftp.openldap.org/incoming/0001-fix-MDB_GET_MULTIPLE-and-MDB_NEXT_MULT… > >> Submission from: (NULL) (84.103.74.130) > >> > >> > >> In a db with MDB_DUPSORT flag, when there is only one DUP data for > >> a key, F_DUPDATA is not set for this key, and there is no > >> sub-cursor. > >> > >> In this case, the current behaviour of MDB_GET_MULTIPLE and > >> MDB_NEXT_MULTIPLE is broken because they make the assumption that > >> there is always a sub-cursor for DUP data, which is only true for > >> keys with more than one DUP data. > >> > >> This patch address this specific issue. > > > > Something's wrong with this patch, it breaks > > MDB_GET_MULTIPLE/NEXT_MULTIPLE usage in slapd. Need to investigate > > further. > > > The original code is correct. GET_MULTIPLE/NEXT_MULTIPLE are only > valid when there actually are duplicate records. MDB_NEXT_MULTIPLE is > essentially just a shortcut for calling MDB_NEXT_DUP in a loop. If > there are no dups, then MDB_NEXT_DUP (and MDB_NEXT_MULTIPLE) return > MDB_NOTFOUND. > > This patch was in mdb.master but has now been reverted. Closing this > ITS. >

1 0

Re: (ITS#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by hyc＠symas.com 15 Apr '13

15 Apr '13

hyc(a)symas.com wrote: > claude.brisson(a)gmail.com wrote: >> Full_Name: Claude Brisson >> Version: HEAD >> OS: linux 64 >> URL: ftp://ftp.openldap.org/incoming/0001-fix-MDB_GET_MULTIPLE-and-MDB_NEXT_MULT… >> Submission from: (NULL) (84.103.74.130) >> >> >> In a db with MDB_DUPSORT flag, when there is only one DUP data for a key, >> F_DUPDATA is not set for this key, and there is no sub-cursor. >> >> In this case, the current behaviour of MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE is >> broken because they make the assumption that there is always a sub-cursor for >> DUP data, which is only true for keys with more than one DUP data. >> >> This patch address this specific issue. > > Something's wrong with this patch, it breaks MDB_GET_MULTIPLE/NEXT_MULTIPLE > usage in slapd. Need to investigate further. > The original code is correct. GET_MULTIPLE/NEXT_MULTIPLE are only valid when there actually are duplicate records. MDB_NEXT_MULTIPLE is essentially just a shortcut for calling MDB_NEXT_DUP in a loop. If there are no dups, then MDB_NEXT_DUP (and MDB_NEXT_MULTIPLE) return MDB_NOTFOUND. This patch was in mdb.master but has now been reverted. Closing this ITS. -- -- 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#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by hyc＠symas.com 15 Apr '13

15 Apr '13

claude.brisson(a)gmail.com wrote: > Full_Name: Claude Brisson > Version: HEAD > OS: linux 64 > URL: ftp://ftp.openldap.org/incoming/0001-fix-MDB_GET_MULTIPLE-and-MDB_NEXT_MULT… > Submission from: (NULL) (84.103.74.130) > > > In a db with MDB_DUPSORT flag, when there is only one DUP data for a key, > F_DUPDATA is not set for this key, and there is no sub-cursor. > > In this case, the current behaviour of MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE is > broken because they make the assumption that there is always a sub-cursor for > DUP data, which is only true for keys with more than one DUP data. > > This patch address this specific issue. Something's wrong with this patch, it breaks MDB_GET_MULTIPLE/NEXT_MULTIPLE usage in slapd. Need to investigate further. -- -- 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#7575) Fixed send_cli_cred on platforms that do not support such functions
by h.b.furuseth＠usit.uio.no 14 Apr '13

14 Apr '13

Ted C. Cheng writes: > I have revised the patch to (1) initialize rname buffer, (2) ignore > the comparison "llen == rlen", Might be OK, but... > (3) compare st.st_mode only against S_IFIFO, but not S_ISUID|S_IRWXU. No. You're getting proper use to work on Solaris, but that's the easy part. That fchmod and corresponding mode test is there for a reason: The code must also reject attempts to impersonate other users or groups. A user could find and open a named socket/pipe owned by some other user, or start someone's setuid program which opens a Unix domain socket and then runs his program as his own user, or something like that. I don't remember exactly. But OSes and OS releases differ about which of these impersonation attempts might work if this code were insufficiently paranoid, so you have quite some exporation work ahead of you if you want to tweak this FD passing safely. You can instead look for a mechanism with built-in credential passing, apparently like Solaris "doors". Or look at what some other well-tested and portable package does and suggest we steal its code. Or live with the fact that SASL/EXTERNAL over ldapi:// is supported on your platform. > The socket path comparison demands full-path match, e.g., > "/var/suum/run/socket" won't match against "/var/suum/run//socket". -- Hallvard

1 0

Re: (ITS#7575) Fixed send_cli_cred on platforms that do not support such functions
by hyc＠symas.com 14 Apr '13

14 Apr '13

tedcheng(a)symas.com wrote: > On Apr 13, 2013, at 12:24 AM, Hallvard Breien Furuseth wrote: > >> Looking again at the st_mode compare: I'm pretty sure the old >> code worked somewhere, at some time. Maybe somewhere it still >> does, and expecting a different fstat():st_mode will break that. >> Unless something changed in OpenLDAP itself? >> >> Anyway, after re-reading ITS#4893 I'd be very wary about tweaking >> this code. Looks like at least I just gave up at the end, but >> followup#9 suggests using Solaris "doors". IIRC I did look at at >> the supposedly more general STREAMS pipes and found myself wading >> into portability issues or kernel tuning params or whateveer. >> >> -- >> Hallvard > > > There are several issues on Solaris 8: > > 1. getsockname(s, (struct sockaddr *)&lname, &llen) > > The llen parameter does not return the actual size of the socket address, > but the original buffer size. As a result, the comparison > !memcmp(&lname, &rname, llen) compares the whole buffer. > Since rname is not initialized to 0 for the entire buffer, the garbage > characters following the socket path name always fail the comparison. > > + if( err == 0 && st.st_mode == mode && llen == rlen > + && !memcmp(&lname, &rname, llen)) > > 2. The checking "llen == rlen" always fails as well. > > 3. The fchmod( fds[0], S_ISUID|S_IRWXU) on the client side does not change > the mode to include S_ISUID|S_IRWXU. The mode stays as only > S_IFIFO: > > (gdb) next > 81 if (rc = fchmod( fds[0], S_ISUID|S_IRWXU ) < 0) { > (gdb) print st > $2 = {...st_mode = 4096, ...} > (gdb) next > 85 (void) fstat(fds[0], &st); > (gdb) next > 86 write( fds[1], sa, salen ); > (gdb) print st > $3 = {...st_mode = 4096, ...} > > Trying to compare (st.st_mode == S_IFIFO|S_ISUID|S_IRWXU) > always fails. As Hallvard points out, all of this code was known to work at one time. Apparently a subsequent Solaris patchlevel has broken it. I don't see a portable way to conditionalize this behavior now. > I have revised the patch to (1) initialize rname buffer, (2) ignore > the comparison "llen == rlen", (3) compare st.st_mode only against > S_IFIFO, but not S_ISUID|S_IRWXU. > > The socket path comparison demands full-path match, e.g., "/var/suum/run/socket" > won't match against "/var/suum/run//socket". Nor should it. In this case whoever is using "//" in the path is misconfigured, as I already said before in private email. > > The revised patch is at: > https://dl.dropboxusercontent.com/u/94235048/ITS7575.patch > > Ted C. Cheng > Symas Corporation -- -- 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#7575) Fixed send_cli_cred on platforms that do not support such functions
by tedcheng＠symas.com 14 Apr '13

14 Apr '13

On Apr 13, 2013, at 12:24 AM, Hallvard Breien Furuseth wrote: > Looking again at the st_mode compare: I'm pretty sure the old > code worked somewhere, at some time. Maybe somewhere it still > does, and expecting a different fstat():st_mode will break that. > Unless something changed in OpenLDAP itself? > > Anyway, after re-reading ITS#4893 I'd be very wary about tweaking > this code. Looks like at least I just gave up at the end, but > followup#9 suggests using Solaris "doors". IIRC I did look at at > the supposedly more general STREAMS pipes and found myself wading > into portability issues or kernel tuning params or whateveer. > > -- > Hallvard There are several issues on Solaris 8: 1. getsockname(s, (struct sockaddr *)&lname, &llen) The llen parameter does not return the actual size of the socket address, but the original buffer size. As a result, the comparison !memcmp(&lname, &rname, llen) compares the whole buffer. Since rname is not initialized to 0 for the entire buffer, the garbage characters following the socket path name always fail the comparison. + if( err == 0 && st.st_mode == mode && llen == rlen + && !memcmp(&lname, &rname, llen)) 2. The checking "llen == rlen" always fails as well. 3. The fchmod( fds[0], S_ISUID|S_IRWXU) on the client side does not change the mode to include S_ISUID|S_IRWXU. The mode stays as only S_IFIFO: (gdb) next 81 if (rc = fchmod( fds[0], S_ISUID|S_IRWXU ) < 0) { (gdb) print st $2 = {...st_mode = 4096, ...} (gdb) next 85 (void) fstat(fds[0], &st); (gdb) next 86 write( fds[1], sa, salen ); (gdb) print st $3 = {...st_mode = 4096, ...} Trying to compare (st.st_mode == S_IFIFO|S_ISUID|S_IRWXU) always fails. I have revised the patch to (1) initialize rname buffer, (2) ignore the comparison "llen == rlen", (3) compare st.st_mode only against S_IFIFO, but not S_ISUID|S_IRWXU. The socket path comparison demands full-path match, e.g., "/var/suum/run/socket" won't match against "/var/suum/run//socket". The revised patch is at: https://dl.dropboxusercontent.com/u/94235048/ITS7575.patch Ted C. Cheng Symas Corporation

1 0

Re: (ITS#7575) Fixed send_cli_cred on platforms that do not support such functions
by h.b.furuseth＠usit.uio.no 13 Apr '13

13 Apr '13

Looking again at the st_mode compare: I'm pretty sure the old code worked somewhere, at some time. Maybe somewhere it still does, and expecting a different fstat():st_mode will break that. Unless something changed in OpenLDAP itself? Anyway, after re-reading ITS#4893 I'd be very wary about tweaking this code. Looks like at least I just gave up at the end, but followup#9 suggests using Solaris "doors". IIRC I did look at at the supposedly more general STREAMS pipes and found myself wading into portability issues or kernel tuning params or whateveer. -- Hallvard

1 0

Re: (ITS#7575) Fixed send_cli_cred on platforms that do not support such functions
by h.b.furuseth＠usit.uio.no 13 Apr '13

13 Apr '13

tedcheng(a)symas.com writes: > URL: https://dl.dropboxusercontent.com/u/94235048/fix_send_cli_cred.patch > > Importing fix from Symas #2230: > > On platforms, such as Solaris 8, that do not support functions for getting > client credential, client sends a message and fd for server to derive euid/egid. > The server-side logic for deriving client credential was buggy. > > This patch introduces sockaddr_un_cmp() to compare the socket path names, > ignoring redundant "/" in the path, and only checks S_IFIFO mode. This patch has > been tested on Solaris 8 and regression-tested fine on Solaris 10. This patch is wrong: - You cannot trust the path which the client wrote to the socket *by hand* (label sendcred: in libldap/os-local.c:ldap_pvt_connect()), if someone else than the owner and root has write access to the socket. Could comment that in getpeereid.c, to prevent such a future patch. - An initial "//" is significant on some systems and must not match "/". Posix does not guarantee that sun_path[] is \0-terminated. What problem is the complicated compare solving? Why not require that the user spells the path like the server does, similar to how TLS hostnames must be spelled the same way? You are not catching all possible spellings of the path anyway: YOu do not reduce "/./" to "/" and must not reduce "foo/../ to "" since foo can be a symlink. -- Hallvard

1 0

(ITS#7575) Fixed send_cli_cred on platforms that do not support such functions
by tedcheng＠symas.com 13 Apr '13

13 Apr '13

Full_Name: Ted C. Cheng Version: HEAD OS: Solaris 8 URL: https://dl.dropboxusercontent.com/u/94235048/fix_send_cli_cred.patch Submission from: (NULL) (76.174.250.179) Importing fix from Symas #2230: On platforms, such as Solaris 8, that do not support functions for getting client credential, client sends a message and fd for server to derive euid/egid. The server-side logic for deriving client credential was buggy. This patch introduces sockaddr_un_cmp() to compare the socket path names, ignoring redundant "/" in the path, and only checks S_IFIFO mode. This patch has been tested on Solaris 8 and regression-tested fine on Solaris 10.

1 0

Re: (ITS#7574) slapo-unique not enforcing uniqueness
by quanah＠zimbra.com 13 Apr '13

13 Apr '13

--On Friday, April 12, 2013 5:48 PM +0000 quanah(a)zimbra.com wrote: > --On Friday, April 12, 2013 5:43 PM +0000 quanah(a)OpenLDAP.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: RE24 4/12/2013 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.39.181) > > Also the following modify succeeds when it should fail: > > zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w > zimbra dc=test zimbraID > dn: dc=test,dc=com > zimbraId: 03ccfb88-cbd8-47e5-94e7-0fb1fa60cacc > > zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w > zimbra dc=example zimbraId > dn: dc=example,dc=com > zimbraId: 0c18e59d-fdd7-40b2-abff-134b118e6cf9 > > zimbra@zre-ldap002:~$ ldapmodify -x -H ldapi:/// -D cn=config -w zimbra > dn: dc=example,dc=com > changetype: modify > replace: zimbraId > zimbraId: 03ccfb88-cbd8-47e5-94e7-0fb1fa60cacc > > modifying entry "dc=example,dc=com" I found it has entirely to do with brand new entries since slapd was last started. unique simply won't enforce on any data added after slapd was started. Restarting slapd results in the correct behavior. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7574) slapo-unique not enforcing uniqueness
by quanah＠zimbra.com 12 Apr '13

12 Apr '13

--On Friday, April 12, 2013 5:43 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 4/12/2013 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.39.181) Also the following modify succeeds when it should fail: zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra dc=test zimbraID dn: dc=test,dc=com zimbraId: 03ccfb88-cbd8-47e5-94e7-0fb1fa60cacc zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra dc=example zimbraId dn: dc=example,dc=com zimbraId: 0c18e59d-fdd7-40b2-abff-134b118e6cf9 zimbra@zre-ldap002:~$ ldapmodify -x -H ldapi:/// -D cn=config -w zimbra dn: dc=example,dc=com changetype: modify replace: zimbraId zimbraId: 03ccfb88-cbd8-47e5-94e7-0fb1fa60cacc modifying entry "dc=example,dc=com" zimbra@zre-ldap002:~$ --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7574) slapo-unique not enforcing uniqueness
by quanah＠OpenLDAP.org 12 Apr '13

12 Apr '13

Full_Name: Quanah Gibson-Mount Version: RE24 4/12/2013 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.39.181) In current RE24, when using the back-mdb backend, uniqueness is no longer enforced. This worked correctly up until at least 2.4.33. dn: olcOverlay={1}unique objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: {1}unique olcUniqueURI: ldap:///?mail?sub olcUniqueURI: ldap:///?zimbraId?sub olcUniqueURI: ldap:///?DKIMSelector?sub so I force uniqueness on "DKIMSelector" It is indexed eq: olcDbIndex: DKIMSelector eq However, adding data for it succeeds when it should be rejected: zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra DKIMSelector=ABCD DKIMSelector dn: dc=test,dc=com DKIMSelector: ABCD dn: dc=example,dc=com DKIMSelector: ABCD

1 0

Re: (ITS#7573) back-perl not working with cn=config
by quanah＠zimbra.com 11 Apr '13

11 Apr '13

--On Thursday, April 11, 2013 6:20 PM +0000 benintechnologies(a)yahoo.fr wrote: > Like I said, if I set back-perl up in slapd.conf mode and then convert it > to cn=config, everything works fine. So how does the ldif generated by slaptest differ from what you are loading? If you slapcat your config that doesn't work, and compare it to the slapcat of what was generated from slaptest, what are the differences? Can you provide a gdb backtrace of the segmentation fault? --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7573) back-perl not working with cn=config
by benintechnologies＠yahoo.fr 11 Apr '13

11 Apr '13

Full_Name: Ben Version: 2.4.34 OS: Debian 6.0.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (41.79.217.116) Hi, I'm unable to set up a back-perl backend directly in cn=config mode. However, if I set it up in slapd.conf mode, and then convert it to cn=config mode, it works fine. It's not convenient, because I have to set all my perl backends up before converting to cn=config. Here's the ldif file I'm using to set up a back-perl backend in cn=config mode (it's inspired from the files I get by converting slapd.conf into cn=config with slaptest) # Load dynamic backend modules dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/local/libexec/openldap olcModuleload: back_perl.la # Database settings dn: olcDatabase=perl,cn=config objectClass: olcDatabaseConfig objectClass: olcDbPerlConfig olcDatabase: perl olcSuffix: dc=mydomain,dc=org olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Manager,dc=mydomain,dc=org olcRootPW:: c2VjcmV0 olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcPerlModulePath: /usr/local/etc/openldap/perl olcPerlModule: SampleLDAP olcPerlFilterSearchResults: FALSE And here's what I get when I try to load the file: ldapadd -Y EXTERNAL -H ldapi:/// -f perl-backend.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=module,cn=config" adding new entry "olcDatabase=perl,cn=config" ldap_result: Can't contact LDAP server (-1) After that, if I start OpenLDAP I get a segmentation fault: root@ldap:/tmp# /usr/local/libexec/slapd -u openldap -g openldap -h "ldap:/// ldapi:///" -d 16383 . 51585496 perl backend db init Segmentation fault Like I said, if I set back-perl up in slapd.conf mode and then convert it to cn=config, everything works fine. Ben

1 0

ITS#6365 Fwd: RE: truncated slapcat output
by hyc＠symas.com 11 Apr '13

11 Apr '13

Fix verified. -------- Original Message -------- Subject: RE: truncated slapcat output Date: Thu, 11 Apr 2013 07:15:17 +0000 From: Hummel, Wolfgang <wolfgang.hummel(a)hp.com> To: Howard Chu <hyc(a)symas.com> Hello Howard, we tested your fix for truncated slapcat and it works fine. Please see test report below. As I am not familiar with your processes in commenting on bugfixes could you use the attached test report and commit the fix so it will become part of next release ? Thanks a lot for your support Regards Wolfgang Hummel Test execution timeframe: April 9th and 10th 2013 Test platform: Hardware HP DL380 G5, 32 GB Memory, 2 Quadcore CPUs OS RedHat 5.1 OpenLDAP 2.4.32 without / with slapcat truncate bugfix bdb backend Test setup: - Subscriber profile DB with 1 Mio. entries, each with 10 attributes Test execution: - ldapbenchmark.pl executing ~ 5 ldapmodifies and ~ 2 ldapsearches / second - slapcat_vfhu_vm_profiles.sh running slapcat in a cycle and counting entries Test result without slapcat truncate bugfix: - 1826 measurements of entry number - 23 events with truncated slapcat output - slapcat return code was always 0 ! Test result with slapcat truncate bugfix: - 1647 measurements of entry number - 0 events with truncated slapcat output script to measure it: #!/bin/bash # run slapcat forever and always count number of entries # they should always be the same while : do slapcat -b ou=vm,ou=profiles,ou=xxxx,c=hu,o=yyyy|grep "^dn:"|wc -l >>vfhu_vm_entries.txt echo "Slapcat Return Code: $?; `date`">>vfhu_vm_entries.txt sleep 1 done log snippet with bug fix: Slapcat Return Code: 0; Wed Apr 10 22:12:42 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 22:13:05 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 22:13:28 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 22:13:52 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 22:14:16 CEST 2013 1000001 log snippet without bugfix: 1000001 Slapcat Return Code: 0; Wed Apr 10 01:01:45 CEST 2013 319284 Slapcat Return Code: 0; Wed Apr 10 01:02:07 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:03:15 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:03:42 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:04:09 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:04:37 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:05:04 CEST 2013 437990 Slapcat Return Code: 0; Wed Apr 10 01:05:16 CEST 2013 146790 Slapcat Return Code: 0; Wed Apr 10 01:05:21 CEST 2013 72688 Slapcat Return Code: 0; Wed Apr 10 01:05:25 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:05:50 CEST 2013 -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Dienstag, 26. März 2013 18:09 To: Hummel, Wolfgang Subject: Re: truncated slapcat output Hummel, Wolfgang wrote: > Hello Howard, > > we are facing in production of our major customer VF the same problems as > described in > > http://www.openldap.org/lists/openldap-technical/201301/msg00232.html > > We are using back-bdb and slapcat to create nightly ldif backups of all DBs > > where 2 of them each contains ~ 40 Mio. entries. > > Even though write traffic is low when the slapcat job runs, every 1 - 2 weeks > > output is truncated without error msg or error return code which creates problems > > for subsequent batch jobs. > > Therefore a slapcat that retries like slapd if a page is locked would be > > really important for us. > > 2 Questions: > > - Is the slapcat retry mechanism the fix you described in > http://www.openldap.org/lists/openldap-technical/201301/msg00232.html ? The patch for ITS#6365 was committed to master commit 853b9d1335d27e280751e9cfb8ca6b5356ffec73 Author: Howard Chu <hyc(a)openldap.org> Date: Thu Feb 7 18:23:25 2013 +0000 ITS#6365 wait for read locks in tool mode > - When will it be available in OpenLDAP ? When somebody follows up to the ITS and confirms that the patch fixes the issue. So far nobody has followed up. You're welcome to test and followup. > > Regards > > Wolfgang Hummel > > ---------------------------------------------------------- > > Postal Address: Hewlett-Packard GmbH > > Wolfgang Hummel > > Enterprise Services > > _/ Communication & Media Solutions > > _/ Herrenberger Str. 140 > > _/_/_/ _/_/_/ 71034 Böblingen > > _/ _/ _/ _/ Phone: +49 7031 14-7375 > > _/ _/ _/_/_/ Fax: +49 711 18562024 > > _/ mobile: +49 151 14751791 > > _/ E-Mail: wolfgang.hummel(a)hp.com > <mailto:wolfgang.hummel@hp.com> > > ---------------------------------------------------------- > > http://www.hp.com/de > > Hewlett-Packard GmbH, Herrenberger Str. 140, 71034 Böblingen > > Geschäftsführer: Volker Smid (Vorsitzender), Martin Kinne, Heiko Meyer, Ernst > Reichart, Rainer Sterk Vorsitzender des Aufsichtsrates: Jörg Menno Harms Sitz > der Gesellschaft: Böblingen, Amtsgericht Stuttgart HRB 244081, WEEE-Reg.-Nr. > DE 30409072 > -- -- 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#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by claude.brisson＠gmail.com 11 Apr '13

11 Apr '13

Full_Name: Claude Brisson Version: HEAD OS: linux 64 URL: ftp://ftp.openldap.org/incoming/0001-fix-MDB_GET_MULTIPLE-and-MDB_NEXT_MULT… Submission from: (NULL) (84.103.74.130) In a db with MDB_DUPSORT flag, when there is only one DUP data for a key, F_DUPDATA is not set for this key, and there is no sub-cursor. In this case, the current behaviour of MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE is broken because they make the assumption that there is always a sub-cursor for DUP data, which is only true for keys with more than one DUP data. This patch address this specific issue. Notice: I, Claude Brisson, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7568) [Patch] Minor documentation fixes
by hyc＠symas.com 11 Apr '13

11 Apr '13

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: master > OS: Linux - Fedora 18 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.132.186.34) > > > I'm attaching two patches that fix minor documentation issues in ldap.conf.5 and > slaptest's usage output. Thanks, added to master. > http://jsynacek.fedorapeople.org/openldap/jsynacek-20130409-0001-Fix-typos-… > http://jsynacek.fedorapeople.org/openldap/jsynacek-20130409-0002-Add-Q-to-s… Personally I don't see much point to -Q here; the purpose of slaptest is to tell you what errors are there. With -Q you get no useful information when an error occurs. Judging from the fact that no one has noticed this omission in the 6 years since -Q was added, I don't believe this particular feature has been of any importance one way or the other. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs