openldap-devel

openldap-devel@openldap.org

1418 discussions

A strange problem while using variable allocated by ber_memalloc_x().
by Chen, Shi Jun SLC CT PEK 27 Nov '06

27 Nov '06

I encount a strange problem while using variable allocated by ber_memalloc_x(). For each operation request, slapd will malloc a buffer to contain the DN and NDN by using ber_memalloc_x() for fields o_req_dn & o_req_ndn in struct operation. Now I want to rewrite the DN and NDN myself, and below is the code. I always get segment fault while running it. But when I set MALLOC_CHECK_, the code does work and will not be crashed. So what's the matter of my code? -Shijun Chen- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ... wrap_dn(op->o_req_dn, op->o_tmpmemctx); ... wrap_dn(struct berval *dn, void *ctx) { char *tmp_buf=NULL, *psub=NULL; int len_tmp_buf=0; lem_tmp_buf = dn->bv_len + 5; dn->bv_val = LDAP_REALLOCX(dn->bv_val, len_tmp_buf, ctx); dn->bv_len = len_tmp_buf; tmp_buf = malloc(len_tmp_buf + 1); memset(tmp_buf, 0, len_tmp_buf + 1); memcpy(tmp_buf, dn->bv_val, len_tmp_buf); psub = strcasestr(tmp_buf, "dc=com"); assert( psub != NULL); sprintf(p_sub, "dc=1,%s", "dc=com"); memcpy(dn->bv_val, tmp_buf, len_tmp_buf); free(tmp_buf); return; } =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

2 1

Re: LDIF parser performance
by Howard Chu 24 Nov '06

24 Nov '06

Michael Ströder wrote: > Howard Chu wrote: >> Try this one instead, I've cleaned up most of that cruft. > > Congratulations! Any chance to see this soon in RE23? The ldapadd code path is solid. The ldapmodify code path is a bit more questionable, mostly because of the ambiguities in the RFC. Let's see what other feedback we get from testing in HEAD... > > It's *much* faster: > > real 0m1.651s > user 0m1.144s > sys 0m0.104s > > instead of: > > real 1m31.305s > user 1m29.730s > sys 0m0.360s > > Ciao, Michael. > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: commit: ldap/servers/slapd proto-slap.h controls.c operation.c
by Howard Chu 24 Nov '06

24 Nov '06

ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > proto-slap.h 1.695 -> 1.696 > controls.c 1.181 -> 1.182 > operation.c 1.76 -> 1.77 > > Log Message: > destroy cached groups after identity change (ITS#4760) I think the groups should not even have been cached in the first place; lookups for auth purposes usually set op->o_nocaching. > > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/ > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/proto-slap.h > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/controls.c > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/operation.c > > Changes are generally available on cvs.openldap.org (and CVSweb) > within 30 minutes of being committed. > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

2 4

authz-policy and rootDSE
by Michael Ströder 22 Nov '06

22 Nov '06

HI! If slapd.conf contains authz-policy none should proxied authorization (2.16.840.1.113730.3.4.18) be advertised in 'supportedControl' of rootDSE? IMHO it shouldn't appear. Ciao, Michael.

2 1

Asyncronous connect(2) in client library?
by Pierangelo Masarati 06 Nov '06

06 Nov '06

The client library seems to allow pretty much asynchronous operations except for connect(2), and I've been requested if it's possible to remove that limitation (?). I see there is code in libraries/libldap/os-ip.c to kinda deal with asynchronous connect(2), but it's protected behind #ifdef notyet lasting since first import from UMIch's ldap-3.3 ('98); does anybody see any issue in working at that that I'm overlooking? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

2 1

chroot'd operation, userid
by Howard Chu 31 Oct '06

31 Oct '06

I was reviewing the discussion of ITS#4719 and thinking about some of the options. We could add a setuser/setgroup config directive for the tools to use. It might be confusing since these directives would not replace the need for slapd's -u and -g commandline options. Along those lines, how does anyone use slapd with the -r option? Since no corresponding option exists for the tools, and presumably the pathnames in slapd.conf are absolute paths, I guess you would need an alternate config for running the tools outside the chroot jail, with the full paths to the jailed directories. Seems rather messy. I would expect the more common scenario is to just run slapd using a userID that doesn't have write privileges outside its database directories, and not worry about a chroot jail. We've talked about this in the past - why don't we restructure things so that the user and group are read from the config, along with the listeners? I.e., defer dropping root privs until after the config has been read. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

3 3

[Fwd: BerkeleyDB region size bug]
by Howard Chu 27 Oct '06

27 Oct '06

This is Sleepycat bug #14908. I thought I posted it here before but apparently not. Fixed in current 4.5.20, but still broken in all earlier releases. -------- Original Message -------- Subject: region size bug Re: [BDB-Alpha] Berkeley DB 4.5.8 ALPHA Date: Mon, 10 Jul 2006 13:37:33 -0700 From: Howard Chu <hyc(a)symas.com> To: support(a)sleepycat.com CC: support(a)symas.com References: <45A742B5-7DD5-4512-A204-A10FE8FC5DFC(a)oracle.com> I just ran into this in 4.2.52 but the same calculation occurs in 4.4 and 4.5.8 alpha: This computation gives the wrong results when the number of cache regions is greater than the number of gigabytes (which we encounter on Linux using shared memory regions, which are constrained to much smaller than a gigabyte each). in mp/mp_region.c: roff_t reg_size; /* Figure out how big each cache region is. */ reg_size = (roff_t)(dbenv->mp_gbytes / dbenv->mp_ncache) * GIGABYTE; reg_size += ((roff_t)(dbenv->mp_gbytes % dbenv->mp_ncache) * GIGABYTE) / dbenv->mp_ncache; reg_size += dbenv->mp_bytes / dbenv->mp_ncache; *reg_sizep = reg_size; The first reg_size calculation always goes to zero when mp_ncache > mp_gbytes. This should have been, instead: reg_size = GIGABYTE / dbenv->mp_ncache * dbenv->mp_gbytes; Or in unidiff: --- mp_region.c.O 2006-06-19 08:37:58.000000000 -0700 +++ mp_region.c 2006-07-10 13:36:43.000000000 -0700 @@ -260,9 +260,7 @@ roff_t reg_size; /* Figure out how big each cache region is. */ - reg_size = (roff_t)(dbenv->mp_gbytes / dbenv->mp_ncache) * GIGABYTE; - reg_size += ((roff_t)(dbenv->mp_gbytes % - dbenv->mp_ncache) * GIGABYTE) / dbenv->mp_ncache; + reg_size = GIGABYTE / dbenv->mp_ncache * dbenv->mp_gbytes; reg_size += dbenv->mp_bytes / dbenv->mp_ncache; *reg_sizep = reg_size; -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: ITS#4703 mirrormode hole
by Aaron Richton 26 Oct '06

26 Oct '06

> While we're at it, we should add a consumer option for specifying > additional locations in which to store contextCSNs. This would e.g. > solve ITS#4626 by allowing a consumer in a glued subordinate to keep its > parent context up to date. One thing we've been kicking around lately was a dream-list feature of "throw a contextcsn on any arbitrary entry." Our motivating problem was essentially + dc=syncproved,dc=rutgers,dc=edu + ou=Boot-Time Configuration + ou=Dynamic Configuration We wanted the ability to arbitrarily add a contextcsn attribute into "ou=Boot-Time Configuration,dc=syncproved,dc=rutgers,dc=edu" despite the fact that the suffix/syncprov was on "dc=syncproved,dc=rutgers,dc=edu". This would be combined with, essentially, /* if bootconfig is fresher than we are, reboot to get it */ if (contextcsn(BootConfig) > (``date`-/proc/uptime`)) restart; to get things that can only be configured at boot time. (No, we're not actualy that crazy with our systems, it's just a daemon; but you get the idea.) In the end, we're just searching for entryCSN>=lastRestart with base of ou=Boot-Time. But contextCSN seems more eloquent (only pick up one entry) and this might be (roughly) in line with what you were considering, or give you some ideas (ridiculous though they might be).

1 0

Re: commit: ldap/servers/slapd passwd.c
by Pierangelo Masarati 26 Oct '06

26 Oct '06

ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > Tag: OPENLDAP_REL_ENG_2_3 > passwd.c 1.95.2.19 -> 1.95.2.20 > > Log Message: > complete fix to ITS#4665 > Note: what we usually do is append modifications to the end of the orm_modlist, so that they get freed along with the others by the caller. In this case, a modification must go first. As a consequence, it wouldn't be freed really. A cleaner approach would be to register another callback that does cleanup of this modification __after__ it's been used. I guess the current approach is just fine, although a bit involved. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

manpages in HEAD
by Howard Chu 26 Oct '06

26 Oct '06

The manpages now source a shared file "../Project". Nothing in the makefiles installs this file, so the Acknowledgements sections of each manpage is empty. This shared file seems to need some re-thinking. Nobody is going to want some generically file named "Project" installed into their /usr/man (or whatever) hierarchy. Perhaps it should be man8/ldap_misc.8 or something, so that at least it has an identifiable name and isn't in the .../man directory. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel