- openldap-bugs - openldap.org

Re: (ITS#6152) proxycache enhancements
by masarati＠aero.polimi.it 20 Aug '09

20 Aug '09

> masarati(a)aero.polimi.it wrote: >> I wonder, in the spirit of further improving pcache: > > I think this should be a separate ITS. Well, based on your response, it seems not to deserve an ITS at all :) >> - support compare, in case a cached query has the entry to be compared, >> and the asserted attr is in the corresponding attrset? > > Right now we have no convenient way to map a DN to a cached query. We have: a cached entry contains the pcacheQueryID, which solves the problem. > I guess > we > could answer if the entry was already retrieved by some other query, but > we > can't tell what the queryID is without first retrieving the entry. Correct. > If the > entry doesn't exist locally, we have no way to map the request to a query > template, so we can't cache that result at all. I was not concerned with *caching* the result of compare, but with exploiting cached entries to answer compares without contacting the remote server. > It seems to me that apps > that > do Compares on a set of entries do that to avoid Searching and retrieving > the > entire entry, so in practice the intersection of (entries cached by > searching) > and (entries we want to compare on) will be empty. :) >> - exploit modifications to invalidate queries whose results are altered? >> It'd be easy for deletes (check if present, and eventually remove the >> entry). An easy shortcut for modify/rename would be to just invalidate >> queries affecting the modified entry (I'd prefer this to mimic >> modifications to local data, which would also guarantee that remote >> server >> ACLs have been applied). Adds would be a little bit tricky (try all >> cached queries on the new entry (base, scope, filter; in case of match, >> invalidate them, so that the remote server can apply ACLs). > >> This may be a moot point, as usually cached proxies are essentially >> read-only, but in case... > > So far no one has asked for this functionality, thankfully. > > We can retrieve an entry and read its queryID but we don't currently have > an > easy way to look up the ID to get the CachedQuery info. This is all already in place as the PCACHE_EXOP_QUERY_DELETE. > (I guess we can > put > them all into an AVL tree for the purpose.) That would make Deletes easy > enough I guess. For Modify/Rename, if you invalidate a query do you then > delete all of the cached entries for that query? That could result in a > lot of > write traffic for a single change. pcache is probably based on the assumption that clients only perform search (and now, bind) operations, so it's a moot point anyway. > Or do you just leave the cached entries > alone, and destroy the CachedQuery structures? Then the entries will > simply > have queryIDs that reference nonexistent queries. > > Yeah, Adds could result in a lot of invalidations too, with the same > question > about dangling queryIDs. Codewise, it's a matter of just calling pcache_remove_entry_queries_from_cache() for the request DN, if the modification succeeds. Performance and load-wise, it might not be worth, I concur. p.

1 0

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

20 Aug '09

masarati(a)aero.polimi.it wrote: > I wonder, in the spirit of further improving pcache: I think this should be a separate ITS. > - support compare, in case a cached query has the entry to be compared, > and the asserted attr is in the corresponding attrset? Right now we have no convenient way to map a DN to a cached query. I guess we could answer if the entry was already retrieved by some other query, but we can't tell what the queryID is without first retrieving the entry. If the entry doesn't exist locally, we have no way to map the request to a query template, so we can't cache that result at all. It seems to me that apps that do Compares on a set of entries do that to avoid Searching and retrieving the entire entry, so in practice the intersection of (entries cached by searching) and (entries we want to compare on) will be empty. > - exploit modifications to invalidate queries whose results are altered? > It'd be easy for deletes (check if present, and eventually remove the > entry). An easy shortcut for modify/rename would be to just invalidate > queries affecting the modified entry (I'd prefer this to mimic > modifications to local data, which would also guarantee that remote server > ACLs have been applied). Adds would be a little bit tricky (try all > cached queries on the new entry (base, scope, filter; in case of match, > invalidate them, so that the remote server can apply ACLs). > This may be a moot point, as usually cached proxies are essentially > read-only, but in case... So far no one has asked for this functionality, thankfully. We can retrieve an entry and read its queryID but we don't currently have an easy way to look up the ID to get the CachedQuery info. (I guess we can put them all into an AVL tree for the purpose.) That would make Deletes easy enough I guess. For Modify/Rename, if you invalidate a query do you then delete all of the cached entries for that query? That could result in a lot of write traffic for a single change. Or do you just leave the cached entries alone, and destroy the CachedQuery structures? Then the entries will simply have queryIDs that reference nonexistent queries. Yeah, Adds could result in a lot of invalidations too, with the same question about dangling queryIDs. -- -- 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#6267) test030-relay fails with back-meta: line 79: kill: (23804) - No such process
by masarati＠aero.polimi.it 20 Aug '09

20 Aug '09

> Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.75.199) > > > No core dump. > >>>>>> waiting for things to exit > > Using meta backend... > > Starting slapd on TCP/IP port 9011... > Using ldapsearch to check that slapd is running... > Using ldapadd to populate the database... > Searching base="dc=example,dc=com"... > Searching base="o=Example,c=US"... > Search failed (255)! > ./scripts/relay: line 79: kill: (23804) - No such process >>>>>> ./scripts/test030-relay failed for bdb (exit 255) > make[2]: *** [bdb-mod] Error 255 > make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make: *** [test] Error 2 > michael@nb2:/usr/src/michael/openldap/HEAD/openldap> cd > /usr/src/michael/openldap/HEAD/openldap/;cvs up -Rd . Can't reproduce. I've refactored that code a little bit, yesterday. I haven't tested building backends as modules, FWIW. Did you start from a fresh checkout? p.

1 0

Re: (ITS#6152) proxycache enhancements
by masarati＠aero.polimi.it 20 Aug '09

20 Aug '09

I wonder, in the spirit of further improving pcache: - support compare, in case a cached query has the entry to be compared, and the asserted attr is in the corresponding attrset? - exploit modifications to invalidate queries whose results are altered? It'd be easy for deletes (check if present, and eventually remove the entry). An easy shortcut for modify/rename would be to just invalidate queries affecting the modified entry (I'd prefer this to mimic modifications to local data, which would also guarantee that remote server ACLs have been applied). Adds would be a little bit tricky (try all cached queries on the new entry (base, scope, filter; in case of match, invalidate them, so that the remote server can apply ACLs). This may be a moot point, as usually cached proxies are essentially read-only, but in case... p.

1 0

(ITS#6267) test030-relay fails with back-meta: line 79: kill: (23804) - No such process
by michael＠stroeder.com 20 Aug '09

20 Aug '09

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.75.199) No core dump. >>>>> waiting for things to exit Using meta backend... Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Searching base="dc=example,dc=com"... Searching base="o=Example,c=US"... Search failed (255)! ./scripts/relay: line 79: kill: (23804) - No such process >>>>> ./scripts/test030-relay failed for bdb (exit 255) make[2]: *** [bdb-mod] Error 255 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make: *** [test] Error 2 michael@nb2:/usr/src/michael/openldap/HEAD/openldap> cd /usr/src/michael/openldap/HEAD/openldap/;cvs up -Rd .

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: > 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 19 Aug '09

19 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 19 Aug '09

19 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 19 Aug '09

19 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

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

18 Aug '09

Just to clarify: there is NO re-entrancy issue. This is essentially about code re-factoring. p.

1 0

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

18 Aug '09

> Open issues: > > - check for re-entrancy of the WIN32 version of lutil_gettime() > > - allow apps to use gmtime(3)/localtime(3) in re-entrant manner when the > _r > replacements are not available (the mutex is no longer exposed) - add function checks to configure. p.

1 0

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

18 Aug '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.235) Submitted by: ando gmtime(3)/gmtime_r(3), localtime(3)/localtime_r(3) can be wrapped in a single place, getting rid of lots of #defines and so. A patch is ready that either provides a re-entrant wrapper or defines the re-entrant functions as macros. Open issues: - check for re-entrancy of the WIN32 version of lutil_gettime() - allow apps to use gmtime(3)/localtime(3) in re-entrant manner when the _r replacements are not available (the mutex is no longer exposed) p.

1 0

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

18 Aug '09

> 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). See ITS#6260 about documenting the behavior with these options :) Note that SASL documentation is itself relatively poor in this area. I could infer the above from code samples 'round, for which is which. p.

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: >> 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.? Ciao, Michael.

1 0

Re: (ITS#6200)
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

> 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? 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#6200)
by imf＠u.washington.edu 18 Aug '09

18 Aug '09

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 #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 --- Tracy Stenvik University Computing Services 354843. University of Washington email: imf(a)u.washington.edu voice: (206) 685-3344 On Thu, 23 Jul 2009, Howard Chu wrote: > imf(a)u.washington.edu wrote: >> The changes made to 2.4.17 seem to have fixed the crashes in the caching >> module. Thanks for that. >> >> We still are able to crash 2.4.17, however. It only happens after a heavy >> load is placed on the producer for>24 hours continuous. Unfortunately, >> we've not been able to get good tracebacks. They all look like this, >> >> (gdb) where >> #0 0x00869410 in __kernel_vsyscall () >> #1 0x00390d80 in raise () from /lib/libc.so.6 >> #2 0x00392691 in abort () from /lib/libc.so.6 >> #3 0x0038a1fb in __assert_fail () from /lib/libc.so.6 >> #4 0x0808d532 in malloc () >> #5 0x0822c93f in ?? () >> #6 0x0822c933 in ?? () >> #7 0x00000039 in ?? () >> #8 0x0822c908 in ?? () >> #9 0x00000000 in ?? () >> >> The producer slowly grows its memory footprint. I can't tell if it's from >> just normal operations or memory leaks. I suspect it's a little of both. >> The end result, as you can see from the core above, is that there's likely >> some corrupted (or unfreed) memory somewhere. Sorry I can't nail it down >> further. > > There's not enough information here. > > An assert is always accompanied by an error message on stderr; we need to see > the actual error message. > > There are no symbols in the stack trace pertaining to slapd itself. You seem > to be running a stripped binary. Please provide a trace using a non-stripped > binary that was compiled with -g (debug symbols enabled). >> >> The load profile that we placed on the server is documented in my prior >> report. See above. > > > -- > -- 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#6194) Patch - Enhancement - provide LDIF support as libldif
by michael＠stroeder.com 18 Aug '09

18 Aug '09

rmeggins(a)redhat.com wrote: > One thing that a general purpose LDIF parser needs is support for change > records - for example, the ability to read in a changetype: modify and > parse the changes into an LDAPMod ** or something like that. There's > already code in ldapmodify to do this, it would need to be refactored > into libldif. There are not only add/modify operations possible in a LDIF file. Personally I'm banging my head about adding full support for change records in python-ldap's LDIF parser. At the end one would have to trigger all LDAP operations including processing of LDAPv3 extended controls. So I guess for a C API this would mean a call-back interface full-featured like libldap itself. (So the next question would be whether to stick with this LDAP C API...) Ciao, Michael.

1 0

Re: (ITS#6261) Misparsing when commas present in LDAP URL DNs
by hyc＠symas.com 18 Aug '09

18 Aug '09

jwm(a)horde.net wrote: > Full_Name: John Morrissey > Version: RE24 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.133.190.110) > > > libldap's ldap_url_parselist_int() splits URLs on spaces (" ") and commas > (",") when parsing them. Commas in LDAP URLs do not need to be > percent-encoded (in fact, section 4 of RFC 4516 has a number of examples > with non-encoded commas). > Perhaps this is a documentation bug. In that case, ldap_open(3) should > mention this behavior, especially since it conflicts with RFC 4516. Looks like a doc bug to me. Note that the commandline tools state explicitly: -H ldapuri Specify URI(s) referring to the ldap server(s); a list of URI, separated by whitespace or commas is expected; only the proto‐ col/host/port fields are allowed. The ldap_open(3) manpage should say the same. -- -- 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#6261) Misparsing when commas present in LDAP URL DNs
by jwm＠horde.net 18 Aug '09

18 Aug '09

Full_Name: John Morrissey Version: RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.133.190.110) libldap's ldap_url_parselist_int() splits URLs on spaces (" ") and commas (",") when parsing them. Commas in LDAP URLs do not need to be percent-encoded (in fact, section 4 of RFC 4516 has a number of examples with non-encoded commas). This causes failure in situations like passing a full URL to ldap_initialize(): ldap_initialize("ldap://localhost/dc=example,dc=com"); Breakpoint 1, ldap_url_parselist_int (ludlist=0x7fff99b56470, url=0x400d10 "ldap://localhost:390/dc=example,dc=com", sep=0x0, flags=3) at url.c:1284 [...] 1293 urls = ldap_str2charray( url, sep ); (gdb) 1294 if (urls == NULL) (gdb) print urls[0] $1 = 0xb69280 "ldap://localhost:390/dc=example" (gdb) print urls[1] $2 = 0xb691b0 "dc=com" ldap_url_parselist_int calls ldap_url_parse_ext() on urls[1], which returns LDAP_URL_ERR_BADSCHEME. This makes its way back to ldap_initialize()'s caller as LDAP_PARAM_ERROR. The client tools accept comma-separated lists of URLs passed to -H. It seems better to modify ldap_url_parselist{,_int}() to split on spaces and use ldap_url_parselist_ext() to override this behavior where necessary for backwards compatibility (such as in client tools). Perhaps this is a documentation bug. In that case, ldap_open(3) should mention this behavior, especially since it conflicts with RFC 4516. >From RFC 4516: -- 2.1. Percent-Encoding A generated LDAP URL MUST consist only of the restricted set of characters included in one of the following three productions defined in [RFC3986]: <reserved> <unreserved> <pct-encoded> Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as input. An octet MUST be encoded using the percent-encoding mechanism described in section 2.1 of [RFC3986] in any of these situations: The octet is not in the reserved set defined in section 2.2 of [RFC3986] or in the unreserved set defined in section 2.3 of [RFC3986]. It is the single Reserved character '?' and occurs inside a <dn>, <filter>, or other element of an LDAP URL. It is a comma character ',' that occurs inside an <exvalue>. Note that before the percent-encoding mechanism is applied, the extensions component of the LDAP URL may contain one or more null (zero) bytes. No other component may. -- And from RFC 2986: -- 2.2. Reserved Characters [...] reserved = gen-delims / sub-delims gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" --

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by rmeggins＠redhat.com 18 Aug '09

18 Aug '09

This is a cryptographically signed message in MIME format. --------------ms040103040408070506080709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit One thing that a general purpose LDIF parser needs is support for change records - for example, the ability to read in a changetype: modify and parse the changes into an LDAPMod ** or something like that. There's already code in ldapmodify to do this, it would need to be refactored into libldif. Since the library should be able to parse any sort of LDIF, the parse function would have to read in the first couple of lines of each LDIF record to determine if it is a plain entry or a change record. The parser would return a struct with a union for the different sets of parameters. The function that parses the LDIF could take a flag (or bitmask) that specifies which types of records it expects (e.g. the LDIF parser usage in slapadd would want to ignore/error on change records). --------------ms040103040408070506080709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJCzCC AuAwggJJoAMCAQICEBMdRWn5u0DKFxH7Tsz20SAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwMzE3Mjk0M1oX DTA5MTIwMzE3Mjk0M1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAG CSqGSIb3DQEJARYTcm1lZ2dpbnNAcmVkaGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMoOfo+aL6KtK5e6tnKn7zhbPm6N1YxeYM5RxJ4v3/winPaNsaYrfcgSKWyy ZH8CLUoKbMndV+/BneBbIFWDNYOZEXs8Yzk0CJtaTchg3sU3yOn7qh38zyzjlSHyXFJyVEJv boTcrdGO2u0WOXj/sH5rIhdguHVcwPUu6ZrTtexqc7887R5SvFRSw3MkKeLWozHB5uQcXZO7 l6LDQU1JQbMAlteZ+fDbEXk8FUclZPg0x/fgIjs+LbPloeUK2qWCk1V85f07C135fzyemy0C MEmkAukakZFgS69Ww1LEPncBfL+5dq9pqHs18QdraT1Vgtzb0tpSPczi9H+/8fTvXwkCAwEA AaMwMC4wHgYDVR0RBBcwFYETcm1lZ2dpbnNAcmVkaGF0LmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBADX7xNlAbUAG6FmqnfEpb5ieewb8OwWT1rZ0X7ZfzM9T0UIOUrN3 2kIhYAcsARWjKbedoinPUWj+a5B+gMTKSaweZ4EZV9LZmtAdvFCJSFsop1ytTeMYapgBLZpZ 02mlCGUK66r256wx645OuWP188Xe6Z34vdtjAesb9ctB27VLMIIC4DCCAkmgAwIBAgIQEx1F afm7QMoXEftOzPbRIDANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDgxMjAzMTcyOTQzWhcNMDkxMjAzMTcyOTQzWjBF MR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSIwIAYJKoZIhvcNAQkBFhNybWVn Z2luc0ByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyg5+j5ov oq0rl7q2cqfvOFs+bo3VjF5gzlHEni/f/CKc9o2xpit9yBIpbLJkfwItSgpsyd1X78Gd4Fsg VYM1g5kRezxjOTQIm1pNyGDexTfI6fuqHfzPLOOVIfJcUnJUQm9uhNyt0Y7a7RY5eP+wfmsi F2C4dVzA9S7pmtO17GpzvzztHlK8VFLDcyQp4tajMcHm5Bxdk7uXosNBTUlBswCW15n58NsR eTwVRyVk+DTH9+AiOz4ts+Wh5QrapYKTVXzl/TsLXfl/PJ6bLQIwSaQC6RqRkWBLr1bDUsQ+ dwF8v7l2r2moezXxB2tpPVWC3NvS2lI9zOL0f7/x9O9fCQIDAQABozAwLjAeBgNVHREEFzAV gRNybWVnZ2luc0ByZWRoYXQuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEA NfvE2UBtQAboWaqd8SlvmJ57Bvw7BZPWtnRftl/Mz1PRQg5Ss3faQiFgBywBFaMpt52iKc9R aP5rkH6AxMpJrB5ngRlX0tma0B28UIlIWyinXK1N4xhqmAEtmlnTaaUIZQrrqvbnrDHrjk65 Y/Xzxd7pnfi922MB6xv1y0HbtUswggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9u IFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftO ucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Va qj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2 0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENB LmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJl bDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0wh uPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmO jCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20C AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBMd RWn5u0DKFxH7Tsz20SAwCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDkwODE4MTcxNzQ5WjAjBgkqhkiG9w0BCQQxFgQUzzoGkS1H KNU2s4j2AyhGil+I2/kwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQEx1Fafm7QMoXEftOzPbRIDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQEx1Fafm7QMoX EftOzPbRIDANBgkqhkiG9w0BAQEFAASCAQBwIGppPuaY7Ou8xa50Lbfui02CjwyRXwZoQskw mBL10x217LurVVMd/lUDafUi1eL1F2BEWapkwmpUCBgIZ5b7OyvQPiupkJkFLcDHwL8PLChp xbNnxjl6bLG1JXmvX96+FiqzS0BeW4xlozkKUcq5sjQX7urtqUfQ+b3YZDEl5Hl9tU8NPBRY R3FPT55LeyqhGk1cfVFso8aIP8CAVhwWmuK1ljm/SukMDNnVllUxOSCJ8uuBBE4fp3H2A9js vsxcGqPQbc9yc7udZxa0nlKA7NtFkSypGqv9V4r6E9lV30K242TdBhC4tazLpH6bgNDpwn6Q x1HbXFdlLiKOVXjHAAAAAAAA --------------ms040103040408070506080709--

1 0

(ITS#6260) ldap_get/set_option() does not document SASL/TLS options
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.235) Submitted by: ando Probably we better expose them in the documentation, although LDAP_OPT_X_*. p.

1 0

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

18 Aug '09

> 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.

1 0

Re: (ITS#6259) test020 core dumps
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

Can't reproduce, although I can see memory leaks (in entry duplication). p.

1 0

(ITS#6259) test020 core dumps
by dieter＠dkluenter.de 18 Aug '09

18 Aug '09

Full_Name: Dieter Kluenter Version: HEAD OS: openSUSE-11.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.154.40.47) my configure flags CFLAGS="-DLDAP_DEVEL -g -march=athlon64" LIBS="-ltcmalloc" ./configure \ --prefix=${PREFIX} \ --enable-dynamic \ --enable-aci \ --enable-modules \ --enable-rewrite \ --enable-bdb=yes \ --enable-hdb=yes \ --enable-ldap=mod \ --enable-monitor=yes \ --enable-meta=mod \ --enable-perl=mod \ --enable-relay=mod \ --enable-monitor=yes \ --enable-sql=mod \ --enable-overlays=mod make depend && make && cd tests test020 core dumps with Core was generated by `/work/ldap-src/servers/slapd/.libs/lt-slapd -s0 -f /work/ldap-src/tests/testrun'. Program terminated with signal 11, Segmentation fault. backtrace is (gdb) bt #0 free (ptr=0x1100ffffff) at src/tcmalloc.cc:842 #1 0x00007f2479ca1bca in ber_memfree_x (p=0x1100ffffff, ctx=0x0) at memory.c:152 #2 0x00007f24753d03a0 in ?? () from /usr/lib64/libldap-2.4.so.2 #3 0x00007f24753b599f in ?? () from /usr/lib64/libldap-2.4.so.2 #4 0x0000000000af9cc8 in ?? () #5 0x0000000000000000 in ?? () (gdb) frame 1 #1 0x00007f2479ca1bca in ber_memfree_x (p=0x1100ffffff, ctx=0x0) at memory.c:152 152 free( p ); Current language: auto; currently c

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by rmeggins＠redhat.com 18 Aug '09

18 Aug '09

Any ideas about what it would take to make a public LDIF API?

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by michael＠stroeder.com 18 Aug '09

18 Aug '09

masarati(a)aero.polimi.it wrote: >> You mean an instance of the allowedAttributesEffective with the empty >> value? I'm not seeing anything like that. > > Actually, I confirm I didn't see anything like that, but there was a bug: > the attribute was being added regardless of having any value, and the > a_numvals field was not being filled in any case. Fixing... Yupp, that seems right now. Ciao, Michael.

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by michael＠stroeder.com 18 Aug '09

18 Aug '09

masarati(a)aero.polimi.it wrote: > Michael Ströder wrote: >> There's a special corner-case: >> If the user bound (e.g. anonymous in my test configuration) has no write >> access to any attribute an empty attribute value list is returned for >> 'allowedAttributesEffective'. > > You mean an instance of the allowedAttributesEffective with the empty > value? Yes. Here's the python-ldap trace log: Note the 'allowedAttributesEffective': [] in the result. I can also enable OpenLDAP debugging log if that would be more evidence for you. ---------------------------- snip ---------------------------- *** ldap://localhost:2071 - LDAPObject.search_ext (('ou=schulung,dc=stroeder,dc=local', 0, '(objectClass=*)', ['hasSubordinates', 'entryCSN', 'tokenGroupsGlobalAndUniversal', 'localEntryID', 'createTimestamp', 'uSNCreated', 'fromEntry', 'administrativeRole', 'structuralObjectClass', 'mS-DS-CreatorSID', 'msDS-Approx-Immed-Subordinates', 'nsAccountLock', 'authzTo', 'nsLookthroughLimit', 'GUID', 'authzFrom', '*', 'passwordExpWarned', 'whenChanged', 'modifiersName', 'isMemberOf', 'sDRightsEffective', 'governingStructureRule', 'primaryGroupToken', 'pwdPolicySubentry', 'accountUnlockTime', 'passwordHistory', 'subordinateCount', 'allowedAttributesEffective', 'creatorsName', 'entryUUID', 'aclentry', 'uSNChanged', 'tokenGroupsNoGCAcceptable', 'entryDN', 'passwordRetryCount', 'tokenGroups', 'passwordExpirationTime', 'aci', 'passwordAllowChangeTime', 'whenCreated', 'retryCountResetTime', 'canonicalName', 'entryUSN', 'subschemaSubentry', 'numSubordinates', 'modifyTimestamp'], 0, [], None, 300, 0),{}) => result: 13 *** ldap://localhost:2071 - LDAPObject.result3 ((13, 1, 300),{}) => result: (101, [('ou=schulung,dc=stroeder,dc=local', {'hasSubordinates': ['TRUE'], 'entryCSN': ['20090818120115.850129Z#000000#000#000000'], 'objectClass': ['organizationalUnit'], 'creatorsName': ['uid=diradm,ou=schulung,dc=stroeder,dc=local'], 'entryUUID': ['d0ed3070-150d-4a5a-bec3-5c21e78c31c3'], 'allowedAttributesEffective': [], 'modifiersName': ['uid=diradm,ou=schulung,dc=stroeder,dc=local'], 'createTimestamp': ['20090818120115Z'], 'entryDN': ['ou=schulung,dc=stroeder,dc=local'], 'subschemaSubentry': ['cn=Subschema'], 'structuralObjectClass': ['organizationalUnit'], 'ou': ['schulung'], 'modifyTimestamp': ['20090818120115Z']})], 13, []) ---------------------------- snip ---------------------------- > I'm not seeing anything like that. At which level? >> Indeed this is helpful since my web2ldap can >> then distinguish between this attribute being not available at all or no >> attributes are allowed to be written. But I'm not sure whether that >> complies >> to the LDAP data model. What do you think? > > In any case, I'd consider it an error, which deserves to be fixed. If you fix it with hunking out the empty values list the distinction within web2ldap would be then to look at the schema and decide whether allowedAttributesEffective is available. I can see that attr type description of allowedAttributesEffective is hard-coded in allowed.c so that seems fairly reliable to me. Ciao, Michael.

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

> You mean an instance of the allowedAttributesEffective with the empty > value? I'm not seeing anything like that. Actually, I confirm I didn't see anything like that, but there was a bug: the attribute was being added regardless of having any value, and the a_numvals field was not being filled in any case. Fixing... p.

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

> I've created a simple Makefile derived from the one for slapo-smbk5pwd for > this I'd like to contribute if appropriate. Please review. I grant *all* > rights to the OpenLDAP project. > > Now for the concrete testing: > > In principle it works. That's great! > > There's a special corner-case: > If the user bound (e.g. anonymous in my test configuration) has no write > access to any attribute an empty attribute value list is returned for > 'allowedAttributesEffective'. You mean an instance of the allowedAttributesEffective with the empty value? I'm not seeing anything like that. > Indeed this is helpful since my web2ldap can > then distinguish between this attribute being not available at all or no > attributes are allowed to be written. But I'm not sure whether that > complies > to the LDAP data model. What do you think? In any case, I'd consider it an error, which deserves to be fixed. p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs