- openldap-bugs - openldap.org

Re: (ITS#6266) uninitialized var in overlays/dynlist.c:dl_cfgen()
by h.b.furuseth＠usit.uio.no 19 Aug '09

19 Aug '09

hyc(a)symas.com writes: > In the actual code, dlm is initialized to NULL. Therefore, dlml will get > initialized to NULL Only initialized when dml is NULL, but the test 'if ( dlml != NULL )' below is unconditional. Then dlml goes out of scope, it doesn't keep the value between iterations. -- Hallvard

1 0

Re: (ITS#6247)
by hyc＠symas.com 19 Aug '09

19 Aug '09

daniel(a)pluta.biz wrote: > Michael Ströder schrieb: >> daniel(a)pluta.biz wrote: >>> Even with the above described limited scope there seem to be plenty of >>> open questions before thinking about "office-hours" and so on. Just two >>> examples regarding the current implementation of now: >>> - The server's timezone vs. the client's timezone (that's more or less >>> obvious - in my opinion it's sufficient to store UTC times). Yes, time is always stored in UTC in the server. >>> - Replication of "now" attributes' values between slapds that are >>> located in different timezones and client's that communicate with these >>> server's... >> IMHO the client has to convert all user input to GMT and convert all server >> results to local timezone for presentation to the user. The server internally >> processes everything as GMT. Maybe I got you wrong though. Other server >> implementations do it this way when checking logon hours. > The server internally compares the (once set) attributes' values against > its current time (whether locale or utc, does not really matter here > essentially it's always used the same - utc or local time) but the > server does not know (IMHO it cannot reliably determine) from which > timezone a client currently is connecting. Imagine a business trip to > Japan (GMT+10) login would not work during the original specified > (European) office hours, even when asking a local replica server in Japan... Right. Which is a good argument against centralized enforcement of general logon hours, since only the client knows what timezone is relevant. Of course, a company with offices in many timezones, and standardized working policies, might use such a mechanism to control the electronic door locks in all of their buildings. In that case it would make sense for the client software to treat the in-directory times as zoneless, or localtime... But I agree, a discussion of how to manipulate timezone information is outside the scope of 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#6266) uninitialized var in overlays/dynlist.c:dl_cfgen()
by h.b.furuseth＠usit.uio.no 19 Aug '09

19 Aug '09

hyc(a)symas.com writes: >> Not even sure about what that piece of code is supposed to do... > > Indeed. It has no visible effect; an optimizer would just elide the > entire block. Sorry, I meant that was the use of _that variable_. There is other code in between. -- Hallvard

1 0

Re: (ITS#6266) uninitialized var in overlays/dynlist.c:dl_cfgen()
by hyc＠symas.com 19 Aug '09

19 Aug '09

hyc(a)symas.com wrote: > masarati(a)aero.polimi.it wrote: >>> gcc complains >>> dynlist.c:1537: warning: 'dlml' may be used uninitialized in this >>> function >>> Looks like its declaration at least should be moved outside the loop below >>> and it should be initialized to something. This is the complete use of >>> dlml: >>> >>> for ( ... ) { >>> dynlist_map_t *dlml; >>> if ( dlm == NULL ) { >>> dlml = NULL; >>> } >>> if ( dlml != NULL ) >>> dlml->dlm_next = dlmp; >>> dlml = dlmp; >>> } >> >> Not even sure about what that piece of code is supposed to do... > > Indeed. It has no visible effect; an optimizer would just elide the entire block. Never mind, the above code snippet was quite abbreviated. In the actual code, dlm is initialized to NULL. Therefore, dlml will get initialized to NULL. The effect is to make sure that new dlmp's are appended to the existing singly-linked list. It's pretty obvious when looking at the actual file. And also obvious that the uninit warning is false. -- -- 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#6266) uninitialized var in overlays/dynlist.c:dl_cfgen()
by hyc＠symas.com 19 Aug '09

19 Aug '09

masarati(a)aero.polimi.it wrote: >> gcc complains >> dynlist.c:1537: warning: 'dlml' may be used uninitialized in this >> function >> Looks like its declaration at least should be moved outside the loop below >> and it should be initialized to something. This is the complete use of >> dlml: >> >> for ( ... ) { >> dynlist_map_t *dlml; >> if ( dlm == NULL ) { >> dlml = NULL; >> } >> if ( dlml != NULL ) >> dlml->dlm_next = dlmp; >> dlml = dlmp; >> } > > Not even sure about what that piece of code is supposed to do... Indeed. It has no visible effect; an optimizer would just elide the entire block. -- -- 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#6161) test058-syncrepl-asymmetric failed (exit 6)
by pchamo2001＠yahoo.com 19 Aug '09

19 Aug '09

Hi all, I'm having similar problems with test058-syncrepl-asymmetric too. I compiled openldap-2.4.17 in several machines under FC3, FC4, and CentOS 5.3 using db-4.6.21.tar.gz, like this: export LD_RUN_PATH=/usr/local/BerkeleyDB.4.6/lib LDFLAGS="-L/usr/local/BerkeleyDB.4.6/lib" CPPFLAGS="-I/usr/local//BerkeleyDB.4.6/include" ./configure --enable-ipv6=no --enable-syslog --enable-slapd --enable-crypt --enable-modules --enable-bdb --enable-hdb --enable-monitor --enable-ldap --enable-accesslog=mod --enable-auditlog=mod --enable-constraint=mod --enable-dyngroup=mod --enable-dynlist=mod --enable-ppolicy=mod --enable-refint=mod --enable-syncprov=mod --enable-unique=mod --enable-valsort=mod --enable-expandurl=mod --enable-static --enable-shared --with-cyrus-sasl --with-tls=openssl; make depend; make; nohup make test -d 16384 & I copied the error messages here: http://correo.ingeominas.gov.co/tmp/ldap/ I wonder if that's right, or else, please just tell me how to run the tests again to get all the debug info possible. Thank you, Pablo Chamorro

1 0

Re: (ITS#6266) uninitialized var in overlays/dynlist.c:dl_cfgen()
by masarati＠aero.polimi.it 19 Aug '09

19 Aug '09

> gcc complains > dynlist.c:1537: warning: 'dlml' may be used uninitialized in this > function > Looks like its declaration at least should be moved outside the loop below > and it should be initialized to something. This is the complete use of > dlml: > > for ( ... ) { > dynlist_map_t *dlml; > if ( dlm == NULL ) { > dlml = NULL; > } > if ( dlml != NULL ) > dlml->dlm_next = dlmp; > dlml = dlmp; > } Not even sure about what that piece of code is supposed to do... p.

1 0

(ITS#6266) uninitialized var in overlays/dynlist.c:dl_cfgen()
by h.b.furuseth＠usit.uio.no 19 Aug '09

19 Aug '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard gcc complains dynlist.c:1537: warning: 'dlml' may be used uninitialized in this function Looks like its declaration at least should be moved outside the loop below and it should be initialized to something. This is the complete use of dlml: for ( ... ) { dynlist_map_t *dlml; if ( dlm == NULL ) { dlml = NULL; } if ( dlml != NULL ) dlml->dlm_next = dlmp; dlml = dlmp; }

1 0

Re: (ITS#6257) libldap: getopt flag to return the SASL username
by michael＠stroeder.com 19 Aug '09

19 Aug '09

masarati(a)aero.polimi.it wrote: >>> It returns whatever returned by sasl_getprop(); it should be a pointer >>> to >>> a zero-terminated string within the SASL context (you don't have to free >>> it, but it may be invalidated when the context is destroyed). >> It seems "you don't have to free it" was the clue! >> Well, it rather means you must not free it. > > I'm documenting options, and noticed that all other values are duplicated > rather than returned as they are. Would you mind reverting the behavior > of this option? I mean: return a LDAP_MALLOC'ed string instead of a > pointer to a string within the SASL handle? I'd appreciate it very much if it would be exactly behave in the same way like all other string-valued options. Ciao, Michael.

1 0

Re: (ITS#6247)
by daniel＠pluta.biz 19 Aug '09

19 Aug '09

Michael Ströder schrieb: > daniel(a)pluta.biz wrote: >> Even with the above described limited scope there seem to be plenty of >> open questions before thinking about "office-hours" and so on. Just two >> examples regarding the current implementation of now: >> - The server's timezone vs. the client's timezone (that's more or less >> obvious - in my opinion it's sufficient to store UTC times). >> - Replication of "now" attributes' values between slapds that are >> located in different timezones and client's that communicate with these >> server's... > > IMHO the client has to convert all user input to GMT and convert all server > results to local timezone for presentation to the user. The server internally > processes everything as GMT. Maybe I got you wrong though. Other server > implementations do it this way when checking logon hours. The server internally compares the (once set) attributes' values against its current time (whether locale or utc, does not really matter here essentially it's always used the same - utc or local time) but the server does not know (IMHO it cannot reliably determine) from which timezone a client currently is connecting. Imagine a business trip to Japan (GMT+10) login would not work during the original specified (European) office hours, even when asking a local replica server in Japan...

1 0

Re: (ITS#6257) libldap: getopt flag to return the SASL username
by masarati＠aero.polimi.it 19 Aug '09

19 Aug '09

>> It returns whatever returned by sasl_getprop(); it should be a pointer >> to >> a zero-terminated string within the SASL context (you don't have to free >> it, but it may be invalidated when the context is destroyed). > > It seems "you don't have to free it" was the clue! > Well, it rather means you must not free it. I'm documenting options, and noticed that all other values are duplicated rather than returned as they are. Would you mind reverting the behavior of this option? I mean: return a LDAP_MALLOC'ed string instead of a pointer to a string within the SASL handle? p.

1 0

Re: (ITS#6264) (docs) Admin guide: bad link in password policy overlay section
by hyc＠symas.com 19 Aug '09

19 Aug '09

jonathan(a)phillipoux.net wrote: > Full_Name: Jonathan Clarke > Version: irrelevant > OS: irrelevant > URL: > Submission from: (NULL) (82.67.204.30) > > > In http://www.openldap.org/doc/admin24/overlays.html#Password%20Policies : > > 8<--------- > Please see slapo-ppolicy(5) for complete explanations of features and discussion > of "Password Management Issues" at > http://www.connexitor.com/forums/viewtopic.php?f=6&t=25 > 8<--------- > > This link leads to a "The requested topic does not exist." error. > Looks like that should now be http://www.symas.com/blog/?page_id=66 I'll fix this. -- -- 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#6247)
by michael＠stroeder.com 19 Aug '09

19 Aug '09

daniel(a)pluta.biz wrote: > Some personal thoughts about locale (timezone) support. This seems to be > by far out of scope and probably completely against the intention of > "now.c". > > How can the timezone be evaluated/specified? I think this can only be > achieved on client-side by specifying some kind of +/-HHMM or > timezone-strings in the matching rule's assertion... > > This offers the possibility to chose a timezone on client side (e.g. a > "window" of 46 hours) which is against the intention of "now". > > now.c's original purpose is strictly limited and specialized on data > privacy requirements. Only the server should decide about a currently > (now) valid entry. I don't want to give a client the chance to variable > request a timestamp (e.g by using a filter or even timezone) of > "personal" interest. > > Even with the above described limited scope there seem to be plenty of > open questions before thinking about "office-hours" and so on. Just two > examples regarding the current implementation of now: > - The server's timezone vs. the client's timezone (that's more or less > obvious - in my opinion it's sufficient to store UTC times). > - Replication of "now" attributes' values between slapds that are > located in different timezones and client's that communicate with these > server's... IMHO the client has to convert all user input to GMT and convert all server results to local timezone for presentation to the user. The server internally processes everything as GMT. Maybe I got you wrong though. Other server implementations do it this way when checking logon hours. Ciao, Michael.

1 0

(ITS#6265) ppolicy: modifications in ppolicy_bind_response don't update entries' operational attributes
by jonathan＠phillipoux.net 19 Aug '09

19 Aug '09

Full_Name: Jonathan Clarke Version: RE24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-ppolicy-20090819.patch Submission from: (NULL) (82.67.204.30) Hi, In the password policy overlay, the function ppolicy_bind_response() contains: Operation op2 = *op; [...] op2.orm_modlist = mod; [...] rc = op2.o_bd->be_modify( &op2, &r2 ); This reuses the original Operation structure (a BIND request) to perform a modification operation. The code changes the value orm_modlist, which is actually in the OpRequest union. This union is thereafter referred to as containing a req_modify_s, not a req_bind_s as before, since this is now a modification operation. However, other fields from req_modify_s are not updated and are interpreted with values set by the bind operation. In particular orm_no_opattrs is set to != 0 (bv_len of the credentials, actually), which causes modifications done by the overlay not to cause updates to operational attributes (which ultimately means these updates are not replicated if we're on a syncrepl provider, which is how I came across this). Sorry for the long explanation, which may seem obvious to those familiar with these structures. The patch above corrects *this* issue. I'm unsure whether orm_increment should also be reset? Probably, I'm guessing. Regards, Jonathan

1 0

(ITS#6264) (docs) Admin guide: bad link in password policy overlay section
by jonathan＠phillipoux.net 19 Aug '09

19 Aug '09

Full_Name: Jonathan Clarke Version: irrelevant OS: irrelevant URL: Submission from: (NULL) (82.67.204.30) In http://www.openldap.org/doc/admin24/overlays.html#Password%20Policies : 8<--------- Please see slapo-ppolicy(5) for complete explanations of features and discussion of "Password Management Issues" at http://www.connexitor.com/forums/viewtopic.php?f=6&t=25 8<--------- This link leads to a "The requested topic does not exist." error.

1 0

(ITS#6247)
by daniel＠pluta.biz 19 Aug '09

19 Aug '09

Some personal thoughts about locale (timezone) support. This seems to be by far out of scope and probably completely against the intention of "now.c". How can the timezone be evaluated/specified? I think this can only be achieved on client-side by specifying some kind of +/-HHMM or timezone-strings in the matching rule's assertion... This offers the possibility to chose a timezone on client side (e.g. a "window" of 46 hours) which is against the intention of "now". now.c's original purpose is strictly limited and specialized on data privacy requirements. Only the server should decide about a currently (now) valid entry. I don't want to give a client the chance to variable request a timestamp (e.g by using a filter or even timezone) of "personal" interest. Even with the above described limited scope there seem to be plenty of open questions before thinking about "office-hours" and so on. Just two examples regarding the current implementation of now: - The server's timezone vs. the client's timezone (that's more or less obvious - in my opinion it's sufficient to store UTC times). - Replication of "now" attributes' values between slapds that are located in different timezones and client's that communicate with these server's...

1 0

Re: (ITS#6152) proxycache enhancements
by hyc＠symas.com 19 Aug '09

19 Aug '09

hyc(a)symas.com wrote: > The TTR feature is now available for testing in HEAD. (As well as the offline > mode switch.) Bind caching is now working in HEAD as well. manpage is up to date, test020 needs some new tests still. Working on that... -- -- 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#6263) Should www.openldap.org still list slurpd on the front page?
by michael＠stroeder.com 19 Aug '09

19 Aug '09

ghenry(a)OpenLDAP.org wrote: > Should www.openldap.org still list slurpd on the front page? IMO no since a link to 2.4.17 is placed on the front page. Ciao, Michael.

1 0

(ITS#6263) Should www.openldap.org still list slurpd on the front page?
by ghenry＠OpenLDAP.org 18 Aug '09

18 Aug '09

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Hi, Should www.openldap.org still list slurpd on the front page? Thanks.

1 0

Re: (ITS#6262) Wrap gmtime(3) for re-entrancy
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

> masarati(a)aero.polimi.it writes: >> PS: need to regenerate configure && portable.h > > And portable.hin. Of course. Those who regenerate it know. > Why not commit them? Because. My autotools usually differ from those used by the project. p.

1 0

Re: (ITS#6262) Wrap gmtime(3) for re-entrancy
by h.b.furuseth＠usit.uio.no 18 Aug '09

18 Aug '09

masarati(a)aero.polimi.it writes: > PS: need to regenerate configure && portable.h And portable.hin. Why not commit them? -- Hallvard

1 0

Re: (ITS#6262) Wrap gmtime(3) for re-entrancy
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

Applied to HEAD, please test. p. PS: need to regenerate configure && portable.h

1 0

Re: (ITS#6257) libldap: getopt flag to return the SASL username
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

>> It returns whatever returned by sasl_getprop(); it should be a pointer >> to >> a zero-terminated string within the SASL context (you don't have to free >> it, but it may be invalidated when the context is destroyed). > > It seems "you don't have to free it" was the clue! > Well, it rather means you must not free it. That's exactly what I meant :) > Ah, nice! web2ldap does not show anonymous anymore when binding to MS AD > with > SASL/GSSAPI. :-) > > Any chance to get this into 2.4.18? Please... ;-) I don't consider this a critical change, so I wouldn't object. Having said this, I wouldn't cry if 2.4.18 is ready and the maintainers do not want to re-package it just because of this fix :) p.

1 0

Re: (ITS#6200)
by imf＠u.washington.edu 18 Aug '09

18 Aug '09

On Tue, 18 Aug 2009, masarati(a)aero.polimi.it wrote: >> Sorry about the stripped trace. I forgot that the install procedure >> always strips the binaries... >> >> Okay, with our stress profile it takes ~36 hours to fail. I always >> start with a clean db rebuild before each run. Each failure produces >> the same traceback: >> >> (gdb) where >> #0 0x00b97410 in __kernel_vsyscall () >> #1 0x00471d80 in raise () from /lib/libc.so.6 >> #2 0x00473691 in abort () from /lib/libc.so.6 >> #3 0x0046b1fb in __assert_fail () from /lib/libc.so.6 >> #4 0x0808d532 in ch_malloc (size=4436335) at ch_malloc.c:57 > > ^^^ this really looks like memory exhaustion while trying to malloc a > large chunk (>4MB). Can you tell, by printing e->e_name, whether it's > correct that the server was modifying a large entry? int entry_encode(Entry *e, struct berval *bv) { ber_len_t len, dnlen, ndnlen, i; int nattrs, nvals; Attribute *a; unsigned char *ptr; Debug( LDAP_DEBUG_TRACE, "=> entry_encode(0x%08lx): %s\n", (long) e->e_id, e->e_dn, 0 ); dnlen = e->e_name.bv_len; ndnlen = e->e_nname.bv_len; entry_partsize( e, &len, &nattrs, &nvals, 1 ); bv->bv_len = len; bv->bv_val = ch_malloc(len); (gdb) p *e $8 = {e_id = 343637, e_name = {bv_len = 0, bv_val = 0x822169c ""}, e_nname = {bv_len = 0, bv_val = 0x822169c ""}, e_attrs = 0x208d270c, e_ocflags = 256, e_bv = {bv_len = 6598587, bv_val = 0x1ddb5008 "\021"}, e_private = 0x9ad5ce0} (gdb) p *bv $2 = {bv_len = 4436293, bv_val = 0x1 <Address 0x1 out of bounds>} (gdb) p nattrs $6 = 16 (gdb) p nvals $7 = 270294 Well, according to e->e_name, e_dn (e_name.bv_val) is empty, so this is likely bogus. We do have some large member entries (>100K) in our test profile, however none add up to anywhere near >4M. Tracy > > p. > >> #5 0x08079ad2 in entry_encode (e=0x3a3dac0, bv=0x3a3d9b0) at entry.c:742 >> #6 0x0815240e in bdb_id2entry_put (be=0x3a3dca0, tid=0xbc6f7378, >> e=0x3a3dac0, flag=0) at id2entry.c:54 >> #7 0x08152508 in hdb_id2entry_update (be=0x3a3dca0, tid=0xbc6f7378, >> e=0x3a3dac0) at id2entry.c:90 >> #8 0x08106374 in hdb_modify (op=0xdabbc28, rs=0x3a3f0e4) at modify.c:611 >> #9 0x080ea38e in overlay_op_walk (op=0xdabbc28, rs=0x3a3f0e4, >> which=op_modify, oi=0x8be2788, on=0x0) at backover.c:669 >> #10 0x080ea543 in over_op_func (op=0xdabbc28, rs=0x3a3f0e4, >> which=op_modify) at backover.c:721 >> #11 0x080ea60b in over_op_modify (op=0xdabbc28, rs=0x3a3f0e4) at >> backover.c:755 >> #12 0x08089151 in fe_op_modify (op=0xdabbc28, rs=0x3a3f0e4) at >> modify.c:301 >> #13 0x08088b90 in do_modify (op=0xdabbc28, rs=0x3a3f0e4) at modify.c:175 >> #14 0x0806be8f in connection_operation (ctx=0x3a3f1d0, arg_v=0xdabbc28) at >> connection.c:1115 >> #15 0x0806c3cf in connection_read_thread (ctx=0x3a3f1d0, argv=0x1a) at >> connection.c:1251 >> #16 0x081d8fa9 in ldap_int_thread_pool_wrapper (xpool=0x8b941b0) at >> tpool.c:685 >> #17 0x0043749b in start_thread () from /lib/libpthread.so.0 >> #18 0x0051a42e in clone () from /lib/libc.so.6 > > >

1 0

Re: (ITS#6257) libldap: getopt flag to return the SASL username
by michael＠stroeder.com 18 Aug '09

18 Aug '09

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it wrote: >>>> libldap should be capable of returning SASL username obtained with >>>> sasl_getprop( sasl_context, SASL_USERNAME, ... ) as result of >>>> ldap_get_option() >>> Added to HEAD (LDAP_OPT_X_SASL_USERNAME); please test. Thanks, p. >> Does it simply return a string like LDAP_OPT_URI, >> LDAP_OPT_X_TLS_CACERTFILE etc.? > > It returns whatever returned by sasl_getprop(); it should be a pointer to > a zero-terminated string within the SASL context (you don't have to free > it, but it may be invalidated when the context is destroyed). It seems "you don't have to free it" was the clue! Well, it rather means you must not free it. Ah, nice! web2ldap does not show anonymous anymore when binding to MS AD with SASL/GSSAPI. :-) Any chance to get this into 2.4.18? Please... ;-) Ciao, Michael.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs