- openldap-bugs - openldap.org

(ITS#4754) Allow a Consumer Syncrepl credentials= to be encrypted liek rootpw
by ghenry＠suretecsystems.com 16 Nov '06

16 Nov '06

Full_Name: Gavin Henry Version: 2.4 OS: FC6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Dear All, In 2.4 would it be possible to let the "credentials" setting under "syncrepl" in a consumer to be encrypted, and not plain text, like the rootpw can be? Many thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

ITS#3812 database config documentation
by hyc＠symas.com 16 Nov '06

16 Nov '06

I've committed a preliminary slapd-config.5 manpage to HEAD. In anticipation of deleting slurpd from RE24, I have commented out all of the slurpd-related keywords. Most of the text is the same as in slapd.conf(5) but I've changed the organization to better reflect the actual implementation. There may be options that I've missed. Please review and send patches / corrections / comments. -- -- 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#4753) Minor section error in slapo-retcode manpage
by ando＠sys-net.it 15 Nov '06

15 Nov '06

gael.roualland(a)oleane.net wrote: > Full_Name: Gaël Roualland > Version: 2.3.30 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.56.0.199) > > > There is a minor typo in slapo-retcode manpage nroff header. > The first line reads: > > .TH SLAPO-RETCODE5 "RELEASEDATE" "OpenLDAP LDVERSION" > > A blank is missing between SLAPO-RETCODE and the section 5. > Fixed, thanks. 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

Re: (ITS#4675) slapd bus error when searching in a subtree
by ghen＠telenet.be 15 Nov '06

15 Nov '06

Why was tick ticket closed? The problem still exists. Geert

1 0

(ITS#4753) Minor section error in slapo-retcode manpage
by gael.roualland＠oleane.net 15 Nov '06

15 Nov '06

Full_Name: Gaël Roualland Version: 2.3.30 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.56.0.199) There is a minor typo in slapo-retcode manpage nroff header. The first line reads: .TH SLAPO-RETCODE5 "RELEASEDATE" "OpenLDAP LDVERSION" A blank is missing between SLAPO-RETCODE and the section 5.

1 0

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by Russ Allbery 15 Nov '06

15 Nov '06

Quanah Gibson-Mount <quanah(a)stanford.edu> writes: > Russ Allbery <rra(a)debian.org> wrote: >> So, what does it do, then? How doesn't it work? What would work >> instead given the above constraint? > I'll note I opened ITS#4750 upstream on this issue. Howard has said > that if a good security argument can be made, it could be committed into > the current (2.3+ releases). The security argument is made in the Debian bug: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387467> specifically: | > I'm curious about this, are you sure a libldap would read an "ldaprc" | > file when run from a setuid program? | | Yep: | | # ls -l /usr/bin/passwd | -rwsr-xr-x 1 root root 32296 2006-08-25 19:49 /usr/bin/passwd | # mv /etc/ldap/ldap.conf /etc/ldap/ldap.conf.away | | $ cd /tmp | $ passwd testuser | passwd: unknown user testuser | $ echo 'TLS_CACERT /etc/ssl/certs/ldapca.pem' > ldaprc | $ passwd testuser | passwd: You may not view or modify password information for testuser. | | > Or that it'd read the | > current-directory ldaprc in that situation? Can you provide an strace | > showing this happening? | | The interesting fragments: | | execve("/usr/bin/passwd", ["passwd", "testuser"], [/* 16 vars */]) = 0 | [...] | access("/etc/suid-debug", F_OK) = -1 ENOENT (No such file or directory) | [...] | getuid32() = 1000 | [...] | geteuid32() = 0 | [...] | open("/etc/libnss-ldap.conf", O_RDONLY) = 3 | [...] | open("/etc/ldap/ldap.conf", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) | open("ldaprc", O_RDONLY|O_LARGEFILE) = 3 | | There is no path component in the last open(), so ldaprc is always read | from the current directory. | | > Also, the user would have to have access to more than the ldaprc file, | > no? Since the user couldn't control what server is being connected to | > without more control on the system, or control over the DNS, etc. | | True, but DNS poisoning is trivial (especially in a large local network | with lots of not-so-trusted machines). If I'd trust the network I'd have | no need for TLS at all... Clearly the user should have an /etc/ldap/ldap.conf under any normal circumstance, and a configuration that does not is most likely broken. However, my argument is that while there may be cases where a user creating a security vulnerability through a broken configuration is simply the user's problem, I believe this is a case where the action taken has no intuitive connection to security. This was initially noticed because a user was putting all their LDAP options in /etc/libnss-ldap.conf rather than in /etc/ldap/ldap.conf, which may be broken but which is not something that is obviously broken from a *security* standpoint. Having a library attempt to open files in the current directory and read them for configuration is highly non-intuitive and unexpected. Having it read configuration out of the user's home directory is less so, but in the case of setuid programs is still rather disturbing, particularly since the setuid program has no direct control over this behavior. So, I see two potential problems here: * A user can override the LDAP configuration of a setuid binary and cause it to, for instance, trust LDAP servers that it wouldn't otherwise trust, which is a potential attack (albeit a difficult one to exploit). If the setuid binary knows that it's using LDAP, it can avoid this via an environment variable, but frequently given such things as NSS plugins and PAM modules the binary isn't going to know that LDAP is involved. The primary problem here is that said setuid binary will read the configuration file based on HOME from the enviroment (it appears to me from the code) or the current directory (the above example), which violates one of the standard secure programming practices for setuid binaries (never trust the process environment including working directory that you're handed by the user). * The library may fall back to reading a file out of the current directory. I don't know if this behavior persists in 2.3; the above example is from 2.1. If it does persist, it opens other potential problems that don't involve setuid but instead involve creating files in the current working directory of a process one wishes to attack. Again, due to the plugin nature of current operating systems, the process being attacked may not even be aware that it's using LDAP. I think this exploit is unlikely to occur in practice since it requires some attacker control over the home directory of the process being attacked, but it's theoretically present. Steve's patch addresses the first issue but doesn't do much about the second, so it's an improvement but I'm not sure it's a complete solution. Unfortunately, this support is also important for the current functionality of the command-line tools and doubtless other programs that use the LDAP libraries. What we ideally need is some way for a user of the LDAP libraries to say, through the API, that user configuration files should not be loaded but that isn't a process-wide flag that interferes with the expected behavior of other uses of LDAP elsewhere in the same process. And as mentioned, I don't see an obvious way to do that without changing the API, which is, of course, a pain. In the meantime, the patch isn't exactly something I'd want to take upstream either, but it at least addresses the most obvious problem, and more problematically I don't see a better way of addressing it other than saying "well, anyone without a system-wide ldap.conf loses." And I wouldn't be comfortable trying to defend that position. I suppose another possible workaround specific to the NSS module (and probably the PAM module as well) would be to proactively check whether there's a system-wide ldap.conf file and fail immediately if there isn't. That leaves the problem open for other setuid uses of the LDAP libraries, but I don't expect there are a lot of those and what ones there may be are more likely to be able to use the LDAPNOINIT flag. -- Russ Allbery (rra(a)debian.org) <http://www.eyrie.org/~eagle/>

2 6

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by hyc＠symas.com 15 Nov '06

15 Nov '06

quanah(a)stanford.edu wrote: > --On Tuesday, November 14, 2006 5:06 AM +0000 Kurt(a)OpenLDAP.org wrote: > > >> I note that nss/pam-ldap setting NOINIT (or otherwise mucking >> with libldap options) might break LDAP-enabled programs. But >> that's another matter. >> >> Anyways, I think the only good fix (for this and many other >> larger problems) is a library redesign/rewrite. > > Okay. > > I note I don't find any mention of NOINIT in the nss_ldap or pam_ldap > source, maybe it was removed at some point? I'm looking at the latest code > from PADL. > > Unless you mean patching nss_ldap/pam_ldap to set "LDAPNOINIT" in the > environment? Which has other problems. For the specific case of nss/pam_ldap the obvious solution is to require that they never use default values anywhere. Generally that is already what happens anyway. -- -- 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

(ITS#4752) back-config Adds are not atomic
by hyc＠OpenLDAP.org 15 Nov '06

15 Nov '06

Full_Name: Howard Chu Version: HEAD/23/24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc When LDAPAdding various types of entries under cn=config, failures in some later portion of the entry will cause the operation to fail but anything already set remains set. The current approach of using check_vals to validate before doing the main processing is inadequate. It may be possible to extend the current pre-check approach, otherwise we'll need to do something like define destructors for everything.

1 0

(ITS#4751) back-perl crashing with anonymous search request
by rhafer＠suse.de 14 Nov '06

14 Nov '06

Full_Name: Ralf Haferkamp Version: HEAD, RE23 OS: SUSE Linux 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.155.116) I created a simple back-perl setup with the SampleLDAP.pm Module (slightly enhanced with a bind() method that just returns SUCCESS) from CVS Head and slapd crashed on me immediately on receiving the first anonymous search request. It survived however when I issued bind requests followed by search request. While digging through the code I found that back_perl_bind calls "PERL_SET_CONTEXT( PERL_INTERPRETER );" since a few revisions. All other back_perl_* functions (search, delete, modify, ...) do not call PERL_SET_CONTEXT, adding that seems to fix the crash. The perlembed man-pages state related to PERL_SET_CONTEXT: "PERL_SET_CONTEXT(interp) should also be called whenever "interp" is used by a thread that did not create it (using either perl_alloc(), ..." I'll commit a fix that adds PERL_SET_CONTEXT calls to the other functions as well (wrapped behind #ifdefs just like in back_perl_bind()).

1 0

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by quanah＠stanford.edu 14 Nov '06

14 Nov '06

--On Tuesday, November 14, 2006 5:06 AM +0000 Kurt(a)OpenLDAP.org wrote: > I note that nss/pam-ldap setting NOINIT (or otherwise mucking > with libldap options) might break LDAP-enabled programs. But > that's another matter. > > Anyways, I think the only good fix (for this and many other > larger problems) is a library redesign/rewrite. Okay. I note I don't find any mention of NOINIT in the nss_ldap or pam_ldap source, maybe it was removed at some point? I'm looking at the latest code from PADL. Unless you mean patching nss_ldap/pam_ldap to set "LDAPNOINIT" in the environment? Which has other problems. >From the source of libldap: init.c: if( getenv("LDAPNOINIT") != NULL ) { --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by Kurt＠OpenLDAP.org 14 Nov '06

14 Nov '06

It was my intent when ldap.conf(5) was designed that it only provide defaults when selected by the user. For instance, a hostname when the user provides none. While libldap always read ldap.conf/.ldaprc, that wasn't considered a big deal. However, with various init options which are used without program selection, programs need now to provide an option to disable initialization. Ugh. I have noted that if I had to do it all over again, libldap would never read ldap.conf(5). Instead the program would have to separately call out to facility to obtain defaults. Some of RRA suggests are not workable. For instance, as now some options can only be set via ldap.conf(5)/.ldaprc, disabling it for root disallows root to use all features of programs and the library. But this is all water under the bridge. The library is what it is. Changing it would likely break other things. I note that nss/pam-ldap setting NOINIT (or otherwise mucking with libldap options) might break LDAP-enabled programs. But that's another matter. Anyways, I think the only good fix (for this and many other larger problems) is a library redesign/rewrite. Kurt At 08:04 PM 11/13/2006, quanah(a)stanford.edu wrote: >Full_Name: Quanah Gibson-Mount >Version: All >OS: NA >URL: >Submission from: (NULL) (171.66.155.86) > > >The debian folks committed the following patch: > >Modified: openldap/trunk-2.1/libraries/libldap/init.c >=================================================================== >--- openldap/trunk-2.1/libraries/libldap/init.c 2006-11-12 10:08:20 UTC (rev >749) >+++ openldap/trunk-2.1/libraries/libldap/init.c 2006-11-14 00:54:38 UTC (rev >750) >@@ -252,6 +252,12 @@ > char *home; > char *path = NULL; > >+ if (getuid() != geteuid()) { >+ /* Caller is setuid -- don't read any per-user configs in >+ these circumstances, as this may not be safe */ >+ return; >+ } >+ > if (file == NULL) { > /* no file name */ > return; > > >You can see this is against 2.1, but the code is essentially the same in OL >HEAD. > >The reason was: > >+ * Don't check for user configuration files when the caller is setuid; >+ addresses #387467, which is a potential security hole allowing >+ libnss-ldap settings to be overridden. Thanks to Stephen Frost for >+ bringing this to my attention. > > >which Howard note is not really the right way to do this. > >[19:07] Howard Chu: that's the wrong fix >[19:07] Howard Chu: libnss-ldap should set NOINIT for its own usage. >[19:09] Quanah: so this patch doesn't really fix anything? >[19:09] Howard Chu: probably not. > > >However, one of my co-workers notes: > > >19:48 <rra@home> Well, I appreciate Howard's opinion here, but that's a crappy >fix because it means that every single binary that uses the LDAP libraries > and may be setuid has to know to do this. >19:49 <rra@home> libnss-ldap should *also* set NOINIT, of course. >19:50 <rra@home> It sounded like it was reading dotfiles out of the user's home >directory, though. >19:50 <rra@home> Is that really what it's doing? >19:50 <rra@home> Something along those lines? >19:50 <Q> http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/init.c?hideattic… >19:50 <Q> it can read .ldaprc, yes >19:50 <rra@home> Libraries reading dotfiles is all by itself pretty evil. >19:51 <rra@home> That to me violates abstraction layers. >19:51 <rra@home> Applications are not going to expect libraries to do that. >19:51 <rra@home> The *right* solution would to me be to not do that; failing >that, I think OpenLDAP should bear the responsibility to do it securely, which > would include not reading user .ldaprc files when running as root. (There >are other ways to prevent that, of course.) >19:55 <rra@home> Basically, my argument is more that there should be a mode that >loads user configuration, but it probably shouldn't be the default > interface. >19:55 <rra@home> Anyway, Howard's certainly right that libnss-ldap needs to be >fixed regardless to pass that flag. > > >So, thoughts appreciated. > >--Quanah

1 0

(ITS#4750) libldap initialization of ~/.ldaprc and setuid
by quanah＠stanford.edu 14 Nov '06

14 Nov '06

Full_Name: Quanah Gibson-Mount Version: All OS: NA URL: Submission from: (NULL) (171.66.155.86) The debian folks committed the following patch: Modified: openldap/trunk-2.1/libraries/libldap/init.c =================================================================== --- openldap/trunk-2.1/libraries/libldap/init.c 2006-11-12 10:08:20 UTC (rev 749) +++ openldap/trunk-2.1/libraries/libldap/init.c 2006-11-14 00:54:38 UTC (rev 750) @@ -252,6 +252,12 @@ char *home; char *path = NULL; + if (getuid() != geteuid()) { + /* Caller is setuid -- don't read any per-user configs in + these circumstances, as this may not be safe */ + return; + } + if (file == NULL) { /* no file name */ return; You can see this is against 2.1, but the code is essentially the same in OL HEAD. The reason was: + * Don't check for user configuration files when the caller is setuid; + addresses #387467, which is a potential security hole allowing + libnss-ldap settings to be overridden. Thanks to Stephen Frost for + bringing this to my attention. which Howard note is not really the right way to do this. [19:07] Howard Chu: that's the wrong fix [19:07] Howard Chu: libnss-ldap should set NOINIT for its own usage. [19:09] Quanah: so this patch doesn't really fix anything? [19:09] Howard Chu: probably not. However, one of my co-workers notes: 19:48 <rra@home> Well, I appreciate Howard's opinion here, but that's a crappy fix because it means that every single binary that uses the LDAP libraries and may be setuid has to know to do this. 19:49 <rra@home> libnss-ldap should *also* set NOINIT, of course. 19:50 <rra@home> It sounded like it was reading dotfiles out of the user's home directory, though. 19:50 <rra@home> Is that really what it's doing? 19:50 <rra@home> Something along those lines? 19:50 <Q> http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/init.c?hideattic… 19:50 <Q> it can read .ldaprc, yes 19:50 <rra@home> Libraries reading dotfiles is all by itself pretty evil. 19:51 <rra@home> That to me violates abstraction layers. 19:51 <rra@home> Applications are not going to expect libraries to do that. 19:51 <rra@home> The *right* solution would to me be to not do that; failing that, I think OpenLDAP should bear the responsibility to do it securely, which would include not reading user .ldaprc files when running as root. (There are other ways to prevent that, of course.) 19:55 <rra@home> Basically, my argument is more that there should be a mode that loads user configuration, but it probably shouldn't be the default interface. 19:55 <rra@home> Anyway, Howard's certainly right that libnss-ldap needs to be fixed regardless to pass that flag. So, thoughts appreciated. --Quanah

1 0

Re: (ITS#4747) Function nisNetgroupTripleValidate fails on underscores
by temp1＠ips.gov.au 14 Nov '06

14 Nov '06

G'Day Kurt Yes, RFC 2307 is restrictive re: limiting the legal character set for the nisNetgroupTripleSyntax values to a "keystring" (ref: RFC 2252). What I find irksome probably boils down to:- Since LDAP was originally designed to gateway requests to X.500 servers that the character set of an IA5String should be legal. (RFC 2307, section 2.4, X.500 nisNetgroupTripleSyntax) With the added twist of the knife, that underscores are legal in the user CN's when doing the nisMapName=netgroup.byuser Note: OS specific "bad chars" still need to be taken into account by the implementer. Since the "nisNetgroupTripleSyntax" is unlikely to change from "keystring" to IA5String in the near future for OpenLDAP, I think I'll have to consider our options re: netgroup configuration and use. Regards IT Manager 2 Kurt D. Zeilenga wrote: > At 09:26 PM 11/12/2006, temp1(a)ips.gov.au wrote: >> Full_Name: IT Manager 2 >> Version: 2.3 & 2.4 >> OS: FreeBSD 6.2-PRERELEASE #0: Thu Oct 19 11:23:22 EST 2006 >> URL: >> Submission from: (NULL) (220.233.132.66) >> >> >> Src ./servers/slapd/schema_init.c >> Function nisNetgroupTripleValidate >> >> Fails validate of NIS Netgroup triplet when an underscore is used in a username, >> hostname or domainname. > > I believe this is the intended behavior. > >> Which is allowable ie username bad chars are " ,\t:+&#%$^()!@~*?<>=|\\/\"". > > RFC 2307 is more restrictive. > > >> suggest change line >> } else if ( !AD_CHAR( *p ) ) { >> to >> } else if ( !(AD_CHAR( *p ) || (*p) == '_' ) ) { >> >> Regards >> IT Manager 2 > >

1 0

Re: (ITS#4749) Missed option in ldap.conf(5)
by ando＠sys-net.it 13 Nov '06

13 Nov '06

Kurt(a)OpenLDAP.org wrote: > Same applies to timeouts as well. Basically, items are intended > to provide defaults for applications which say "use default". > Having options, such as this and various timeouts, which get used > by the library without application saying "use default" are > quite problematic and should be avoided. > See my comment above; ldap.conf(5) sounds like a good place to put parameters that existing applications wouldn't allow. Maybe allowing things like timeouts as user-only would be a solution, since a user can force LDAPCONF for specific applications and alter their behavior. By now, I'd remove the RESTART option but leave the NETWORK_TIMEOUT in place. 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

Re: (ITS#4749) Missed option in ldap.conf(5)
by ando＠sys-net.it 13 Nov '06

13 Nov '06

hyc(a)symas.com wrote: > As I recall there was some debate about making this available in > ldap.conf, since setting it globally can break some applications that > aren't expecting one behavior or another. I believe the option should > remain undocumented, and the support for parsing it from ldap.conf > should likely be removed. It should only be available when a program > specifically requests it via ldap_set_option. > OK; I don't recall discussions about that. I've cleaned up code and man pages in HEAD. Maybe parsing could be only allowed from user files, but right now I'm just removing it. 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

Re: (ITS#4749) Missed option in ldap.conf(5)
by Kurt＠OpenLDAP.org 13 Nov '06

13 Nov '06

At 02:16 PM 11/13/2006, hyc(a)symas.com wrote: >As I recall there was some debate about making this available in >ldap.conf, since setting it globally can break some applications that >aren't expecting one behavior or another. I believe the option should >remain undocumented, and the support for parsing it from ldap.conf >should likely be removed. It should only be available when a program >specifically requests it via ldap_set_option. Same applies to timeouts as well. Basically, items are intended to provide defaults for applications which say "use default". Having options, such as this and various timeouts, which get used by the library without application saying "use default" are quite problematic and should be avoided. Kurt

1 0

Re: (ITS#4749) Missed option in ldap.conf(5)
by hyc＠symas.com 13 Nov '06

13 Nov '06

ando(a)sys-net.it wrote: > tiamat(a)komi.mts.ru wrote: >> Full_Name: Alex Deiter >> Version: 2.3.29 >> OS: Solaris 9 sparc >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (217.66.145.224) >> >> >> Hi, >> >> I have found undocumented parameter for ldap.conf in libraries/libldap/init.c: >> RESTART, >> and has written the missed section for ldap.conf(5): >> >> ftp://ftp.openldap.org/incoming/alex-deiter-061111.patch >> > This option has been recently documented in ldap_get_option(3), but > honestly it's not clear to me what its intended usage is. I'll check > your patch and eventually apply it to HEAD. As I recall there was some debate about making this available in ldap.conf, since setting it globally can break some applications that aren't expecting one behavior or another. I believe the option should remain undocumented, and the support for parsing it from ldap.conf should likely be removed. It should only be available when a program specifically requests it via ldap_set_option. -- -- 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#4749) Missed option in ldap.conf(5)
by ando＠sys-net.it 13 Nov '06

13 Nov '06

tiamat(a)komi.mts.ru wrote: > Full_Name: Alex Deiter > Version: 2.3.29 > OS: Solaris 9 sparc > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.66.145.224) > > > Hi, > > I have found undocumented parameter for ldap.conf in libraries/libldap/init.c: > RESTART, > and has written the missed section for ldap.conf(5): > > ftp://ftp.openldap.org/incoming/alex-deiter-061111.patch > This option has been recently documented in ldap_get_option(3), but honestly it's not clear to me what its intended usage is. I'll check your patch and eventually apply it to HEAD. Thanks, p.

1 0

Re: (ITS#4748) Implement [NETWORK_]TIMEOUT options for ldap.conf
by ando＠sys-net.it 13 Nov '06

13 Nov '06

tiamat(a)komi.mts.ru wrote: > Full_Name: Alex Deiter > Version: 2.3.29 > OS: Solaris 9 sparc > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.66.145.224) > > > Hi, > > Please review my patch which implement two new ldap.conf options: TIMEOUT and > NETWORK_TIMEOUT. These options are very useful to the wide list of applications, > which do not operate these parameters directly: samba, isc dhcp/bind, sendmail > and many other things. > > I offer two variants: with use ldap_set_option: > > ftp://ftp.openldap.org/incoming/alex-deiter-061112.patch > > and without it: > > ftp://ftp.openldap.org/incoming/alex-deiter-061113.patch > Usually, only patches for HEAD code are considered, unless they are specifically intended to fix bugs in release code. TIMEOUT is right now unused in the code; have no idea what it was originally intended for. Support for NETWORK_TIMEOUT in ldap.conf is already implemented in HEAD; OpenLDAP 2.3 is feature frozen, so it's unlikely that it will be backported, as it's not a major bug but rather a missing feature. p.

1 0

(ITS#4749) Missed option in ldap.conf(5)
by tiamat＠komi.mts.ru 13 Nov '06

13 Nov '06

Full_Name: Alex Deiter Version: 2.3.29 OS: Solaris 9 sparc URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.66.145.224) Hi, I have found undocumented parameter for ldap.conf in libraries/libldap/init.c: RESTART, and has written the missed section for ldap.conf(5): ftp://ftp.openldap.org/incoming/alex-deiter-061111.patch Thanks a lot!

1 0

(ITS#4748) Implement [NETWORK_]TIMEOUT options for ldap.conf
by tiamat＠komi.mts.ru 13 Nov '06

13 Nov '06

Full_Name: Alex Deiter Version: 2.3.29 OS: Solaris 9 sparc URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.66.145.224) Hi, Please review my patch which implement two new ldap.conf options: TIMEOUT and NETWORK_TIMEOUT. These options are very useful to the wide list of applications, which do not operate these parameters directly: samba, isc dhcp/bind, sendmail and many other things. I offer two variants: with use ldap_set_option: ftp://ftp.openldap.org/incoming/alex-deiter-061112.patch and without it: ftp://ftp.openldap.org/incoming/alex-deiter-061113.patch Thanks a lot!

1 0

Re: (ITS#4747) Function nisNetgroupTripleValidate fails on underscores
by Kurt＠OpenLDAP.org 13 Nov '06

13 Nov '06

At 09:26 PM 11/12/2006, temp1(a)ips.gov.au wrote: >Full_Name: IT Manager 2 >Version: 2.3 & 2.4 >OS: FreeBSD 6.2-PRERELEASE #0: Thu Oct 19 11:23:22 EST 2006 >URL: >Submission from: (NULL) (220.233.132.66) > > >Src ./servers/slapd/schema_init.c >Function nisNetgroupTripleValidate > >Fails validate of NIS Netgroup triplet when an underscore is used in a username, >hostname or domainname. I believe this is the intended behavior. >Which is allowable ie username bad chars are " ,\t:+&#%$^()!@~*?<>=|\\/\"". RFC 2307 is more restrictive. >suggest change line > } else if ( !AD_CHAR( *p ) ) { > to > } else if ( !(AD_CHAR( *p ) || (*p) == '_' ) ) { > >Regards >IT Manager 2

1 0

(ITS#4747) Function nisNetgroupTripleValidate fails on underscores
by temp1＠ips.gov.au 13 Nov '06

13 Nov '06

Full_Name: IT Manager 2 Version: 2.3 & 2.4 OS: FreeBSD 6.2-PRERELEASE #0: Thu Oct 19 11:23:22 EST 2006 URL: Submission from: (NULL) (220.233.132.66) Src ./servers/slapd/schema_init.c Function nisNetgroupTripleValidate Fails validate of NIS Netgroup triplet when an underscore is used in a username, hostname or domainname. Which is allowable ie username bad chars are " ,\t:+&#%$^()!@~*?<>=|\\/\"". suggest change line } else if ( !AD_CHAR( *p ) ) { to } else if ( !(AD_CHAR( *p ) || (*p) == '_' ) ) { Regards IT Manager 2

1 0

(ITS#4746) memory leak in syncrepl consumer
by hyc＠OpenLDAP.org 13 Nov '06

13 Nov '06

Full_Name: Howard Chu Version: RE23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc syncrepl_updateCookie leaks the CSN that it queues up. Detected with valgrind.

1 0

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by hyc＠symas.com 12 Nov '06

12 Nov '06

Pierangelo Masarati wrote: > Howard Chu wrote: >> OK. And we have usually used DEBUG_ANY for fatal messages of this >> type. The point I'm making now is that config errors are no longer >> always fatal; it depends on whether we're starting up or already running. > But right now all errors like that are LDAP_DEBUG_CONFIG. Since tools > now run with LDAP_DEBUG_NONE set, ORin LDAP_DEBUG_NONE to fatal messages > would let them always pop up with tools __and__ run-time; run-time it > shouldn't be a big deal, it's just another informative message in the > logs; with the tools it should make the difference. I have no > preference for either way: add LDAP_DEBUG_CONFIG_FATAL, enabled by > default in tools, or OR config messages with LDAP_DEBUG_NONE. OK, that makes sense. Perhaps we should define LDAP_DEBUG_ERROR (or _FATAL) as an alias of LDAP_DEBUG_NONE. -- -- 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#4742) parameter unique_attributes and unknown attribute types
by ando＠sys-net.it 12 Nov '06

12 Nov '06

Howard Chu wrote: > OK. And we have usually used DEBUG_ANY for fatal messages of this > type. The point I'm making now is that config errors are no longer > always fatal; it depends on whether we're starting up or already running. But right now all errors like that are LDAP_DEBUG_CONFIG. Since tools now run with LDAP_DEBUG_NONE set, ORin LDAP_DEBUG_NONE to fatal messages would let them always pop up with tools __and__ run-time; run-time it shouldn't be a big deal, it's just another informative message in the logs; with the tools it should make the difference. I have no preference for either way: add LDAP_DEBUG_CONFIG_FATAL, enabled by default in tools, or OR config messages with LDAP_DEBUG_NONE. 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

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by hyc＠symas.com 12 Nov '06

12 Nov '06

ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >> Another possibility would be to always enable LDAP_DEBUG_CONFIG for the >> tools. The only reason I suggest this is because I would prefer that >> runtime configuration errors are only logged when specifically >> requested, not at DEBUG_ANY. Since the error messages are already >> returnes to the client in the protocol, it's not always necessary to log >> them separately. >> > The point is that I'd like to separate informative messages about > configuration (LDAP_DEBUG_CONFIG) from __the__ message that described > why slaptest failed (or slapd refuses to start). Right now, either you > get all (which is annoying) or none (which is frustrating). Apparently, > unless we hijack LDAP_DEBUG_NONE for the duration of config parsing, and > OR it to all messages followed by "return ARG_BAD_CONF;", we need > another LDAP_DEBUG_*. OK. And we have usually used DEBUG_ANY for fatal messages of this type. The point I'm making now is that config errors are no longer always fatal; it depends on whether we're starting up or already running. -- -- 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#4742) parameter unique_attributes and unknown attribute types
by ando＠sys-net.it 12 Nov '06

12 Nov '06

hyc(a)symas.com wrote: > Another possibility would be to always enable LDAP_DEBUG_CONFIG for the > tools. The only reason I suggest this is because I would prefer that > runtime configuration errors are only logged when specifically > requested, not at DEBUG_ANY. Since the error messages are already > returnes to the client in the protocol, it's not always necessary to log > them separately. > The point is that I'd like to separate informative messages about configuration (LDAP_DEBUG_CONFIG) from __the__ message that described why slaptest failed (or slapd refuses to start). Right now, either you get all (which is annoying) or none (which is frustrating). Apparently, unless we hijack LDAP_DEBUG_NONE for the duration of config parsing, and OR it to all messages followed by "return ARG_BAD_CONF;", we need another LDAP_DEBUG_*. 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

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by hyc＠symas.com 11 Nov '06

11 Nov '06

ando(a)sys-net.it wrote: > michael(a)stroeder.com wrote: >> It seems that slapd stops without configuration error message if unknown >> attribute types are set for parameter unique_attributes (slapo-unique). It would >> be nice if a descriptive message is displayed (like in other cases). >> > I think this occurs if debug is set to "config" or "-1". However, it > would be more appropriate to log configuration errors that result in > failures at "any", so that whatever logging is set they show up. For > this purpose, many of the current occurrences of LDAP_DEBUG_CONFIG > should be turned into (LDAP_DEBUG_CONFIG | LDAP_DEBUG_NONE), so that > they show up when caught by tools with default logging (e.g. > slaptest(8)), or into LDAP_DEBUG_ANY, so that they show up all times. > I'd vote for the latter. Another possibility would be to always enable LDAP_DEBUG_CONFIG for the tools. The only reason I suggest this is because I would prefer that runtime configuration errors are only logged when specifically requested, not at DEBUG_ANY. Since the error messages are already returnes to the client in the protocol, it's not always necessary to log them separately. -- -- 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#4745) libslapi undefined symbols
by quanah＠stanford.edu 11 Nov '06

11 Nov '06

--On Saturday, November 11, 2006 9:10 PM +0000 hyc(a)symas.com wrote: > quanah(a)stanford.edu wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.3.28 >> OS: Linux 2.6 64-bit >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (171.66.155.86) >> >> >> When building OpenLDAP 2.3.28, I found that libslapi is full of undefined >> symbols. Is it not being linked correctly? >> > Do you actually have a slapi plugin that isn't working? There's no > evidence of a bug here. Most dynamic libraries that depend on other > objects are full of undefined symbols. Nope, I don't use slapi at all, other than to enable it to disable the broken acl cacheing in 2.3. Thanks. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4745) libslapi undefined symbols
by hyc＠symas.com 11 Nov '06

11 Nov '06

quanah(a)stanford.edu wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.28 > OS: Linux 2.6 64-bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.66.155.86) > > > When building OpenLDAP 2.3.28, I found that libslapi is full of undefined > symbols. Is it not being linked correctly? > Do you actually have a slapi plugin that isn't working? There's no evidence of a bug here. Most dynamic libraries that depend on other objects are full of undefined symbols. -- -- 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

(ITS#4745) libslapi undefined symbols
by quanah＠stanford.edu 11 Nov '06

11 Nov '06

Full_Name: Quanah Gibson-Mount Version: 2.3.28 OS: Linux 2.6 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) When building OpenLDAP 2.3.28, I found that libslapi is full of undefined symbols. Is it not being linked correctly? ldap-uat00:/usr/local/stow/openldap-2.3.28.9-gcc411/lib> ldd libslapi.so libc.so.6 => /lib/libc.so.6 (0x00002b58357d6000) /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) ldap-uat00:/usr/local/stow/openldap-2.3.28.9-gcc411/lib> ldd -r -d libslapi-2.3.so.0.2.16 libc.so.6 => /lib/libc.so.6 (0x00002adf05784000) /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) undefined symbol: slap_schema (./libslapi-2.3.so.0.2.16) undefined symbol: sockbuf_max_incoming (./libslapi-2.3.so.0.2.16) undefined symbol: ch_mfuncs (./libslapi-2.3.so.0.2.16) undefined symbol: slap_send_ldap_extended (./libslapi-2.3.so.0.2.16) undefined symbol: slap_cids (./libslapi-2.3.so.0.2.16) undefined symbol: slap_unknown_bv (./libslapi-2.3.so.0.2.16) undefined symbol: frontendDB (./libslapi-2.3.so.0.2.16) undefined symbol: sockbuf_max_incoming_auth (./libslapi-2.3.so.0.2.16) undefined symbol: local_ssf (./libslapi-2.3.so.0.2.16) undefined symbol: slap_debug (./libslapi-2.3.so.0.2.16) undefined symbol: slap_send_search_entry (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_syslog_level (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_syslog (./libslapi-2.3.so.0.2.16) undefined symbol: slap_send_ldap_result (./libslapi-2.3.so.0.2.16) undefined symbol: slap_send_search_reference (./libslapi-2.3.so.0.2.16) undefined symbol: entry2str_mutex (./libslapi-2.3.so.0.2.16) undefined symbol: be_isroot (./libslapi-2.3.so.0.2.16) undefined symbol: slapi_plugins_used (./libslapi-2.3.so.0.2.16) undefined symbol: be_slurp_update (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_cond_init (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_cond_broadcast (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_mods_free (./libslapi-2.3.so.0.2.16) undefined symbol: lutil_strcopy (./libslapi-2.3.so.0.2.16) undefined symbol: slap_mods_check (./libslapi-2.3.so.0.2.16) undefined symbol: value_add_one (./libslapi-2.3.so.0.2.16) undefined symbol: attr_merge_normalize_one (./libslapi-2.3.so.0.2.16) undefined symbol: rdn_validate (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_pool_context (./libslapi-2.3.so.0.2.16) undefined symbol: ber_dupbv (./libslapi-2.3.so.0.2.16) undefined symbol: get_supported_extop (./libslapi-2.3.so.0.2.16) undefined symbol: attr_merge_normalize (./libslapi-2.3.so.0.2.16) undefined symbol: ch_free (./libslapi-2.3.so.0.2.16) undefined symbol: modify_add_values (./libslapi-2.3.so.0.2.16) undefined symbol: ber_sockbuf_free (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_cond_signal (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_mutex_unlock (./libslapi-2.3.so.0.2.16) undefined symbol: be_issuffix (./libslapi-2.3.so.0.2.16) undefined symbol: ch_calloc (./libslapi-2.3.so.0.2.16) undefined symbol: slap_sl_free (./libslapi-2.3.so.0.2.16) undefined symbol: anlist2charray_x (./libslapi-2.3.so.0.2.16) undefined symbol: ch_strdup (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_bv2rdn (./libslapi-2.3.so.0.2.16) undefined symbol: value_match (./libslapi-2.3.so.0.2.16) undefined symbol: slap_str2ad (./libslapi-2.3.so.0.2.16) undefined symbol: overlay_is_inst (./libslapi-2.3.so.0.2.16) undefined symbol: ber_bvfree (./libslapi-2.3.so.0.2.16) undefined symbol: is_ad_subtype (./libslapi-2.3.so.0.2.16) undefined symbol: access_allowed_mask (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_mutex_destroy (./libslapi-2.3.so.0.2.16) undefined symbol: dnExtractRdn (./libslapi-2.3.so.0.2.16) undefined symbol: send_ldap_sasl (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_charray_dup (./libslapi-2.3.so.0.2.16) undefined symbol: register_supported_control (./libslapi-2.3.so.0.2.16) undefined symbol: slap_mods2entry (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_cond_wait (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_rdnfree (./libslapi-2.3.so.0.2.16) undefined symbol: ber_bvarray_add (./libslapi-2.3.so.0.2.16) undefined symbol: be_entry_get_rw (./libslapi-2.3.so.0.2.16) undefined symbol: dnPrettyNormal (./libslapi-2.3.so.0.2.16) undefined symbol: select_backend (./libslapi-2.3.so.0.2.16) undefined symbol: dnParent (./libslapi-2.3.so.0.2.16) undefined symbol: lt_dlerror (./libslapi-2.3.so.0.2.16) undefined symbol: attr_delete (./libslapi-2.3.so.0.2.16) undefined symbol: be_entry_release_rw (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_bv2dn (./libslapi-2.3.so.0.2.16) undefined symbol: str2entry (./libslapi-2.3.so.0.2.16) undefined symbol: dnNormalize (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_initialize (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_mutex_lock (./libslapi-2.3.so.0.2.16) undefined symbol: get_supported_controls (./libslapi-2.3.so.0.2.16) undefined symbol: lt_dlclose (./libslapi-2.3.so.0.2.16) undefined symbol: entry_alloc (./libslapi-2.3.so.0.2.16) undefined symbol: slap_parse_ctrl (./libslapi-2.3.so.0.2.16) undefined symbol: entry2str (./libslapi-2.3.so.0.2.16) undefined symbol: entry_dup (./libslapi-2.3.so.0.2.16) undefined symbol: slap_entry2mods (./libslapi-2.3.so.0.2.16) undefined symbol: overlay_op_walk (./libslapi-2.3.so.0.2.16) undefined symbol: rdnNormalize (./libslapi-2.3.so.0.2.16) undefined symbol: str2filter (./libslapi-2.3.so.0.2.16) undefined symbol: filter_free (./libslapi-2.3.so.0.2.16) undefined symbol: attr_find (./libslapi-2.3.so.0.2.16) undefined symbol: ber_sockbuf_alloc (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_rdn2bv (./libslapi-2.3.so.0.2.16) undefined symbol: entry_free (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_dnfree (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_str2rdn (./libslapi-2.3.so.0.2.16) undefined symbol: dnIsSuffix (./libslapi-2.3.so.0.2.16) undefined symbol: rdnMatch (./libslapi-2.3.so.0.2.16) undefined symbol: ber_bvarray_free (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_unbind_ext_s (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_charray_free (./libslapi-2.3.so.0.2.16) undefined symbol: test_filter (./libslapi-2.3.so.0.2.16) undefined symbol: lt_dlopen (./libslapi-2.3.so.0.2.16) undefined symbol: overlay_register (./libslapi-2.3.so.0.2.16) undefined symbol: modify_delete_values (./libslapi-2.3.so.0.2.16) undefined symbol: attr_free (./libslapi-2.3.so.0.2.16) undefined symbol: backend_connection_init (./libslapi-2.3.so.0.2.16) undefined symbol: build_new_dn (./libslapi-2.3.so.0.2.16) undefined symbol: entry_schema_check (./libslapi-2.3.so.0.2.16) undefined symbol: ad_inlist (./libslapi-2.3.so.0.2.16) undefined symbol: filter2bv_x (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_mutex_init (./libslapi-2.3.so.0.2.16) undefined symbol: ber_sockbuf_ctrl (./libslapi-2.3.so.0.2.16) undefined symbol: attr_dup (./libslapi-2.3.so.0.2.16) undefined symbol: connection_assign_nextid (./libslapi-2.3.so.0.2.16) undefined symbol: ch_realloc (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_controls_free (./libslapi-2.3.so.0.2.16) undefined symbol: mods_structural_class (./libslapi-2.3.so.0.2.16) undefined symbol: lt_dlsym (./libslapi-2.3.so.0.2.16) undefined symbol: filter_dup (./libslapi-2.3.so.0.2.16) undefined symbol: dnPretty (./libslapi-2.3.so.0.2.16) undefined symbol: slap_bv2ad (./libslapi-2.3.so.0.2.16) undefined symbol: acl_check_modlist (./libslapi-2.3.so.0.2.16) undefined symbol: dnMatch (./libslapi-2.3.so.0.2.16) undefined symbol: slap_mods_free (./libslapi-2.3.so.0.2.16) undefined symbol: ch_malloc (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_cond_destroy (./libslapi-2.3.so.0.2.16) undefined symbol: lt_dlinit (./libslapi-2.3.so.0.2.16) undefined symbol: overlay_config (./libslapi-2.3.so.0.2.16)

1 0

Re: (ITS#4744) Bug in SASL authzTo validation using an ldap:// rule
by hyc＠symas.com 11 Nov '06

11 Nov '06

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> As far as I remember, that test is intended to prevent mapping when the >> search returns more than one entry. This makes perfectly sense, >> otherwise a SASL identity (or an authorization identity) would be >> arbitrarily mapped to one of the matching entries. So mapping is >> intended to succeed if and only if exactly one identity can be resolved. > > That test is only supposed to prevent mapping when doing an authzRegexp > mapping of a single SASL userID to a DN. When looking up > authzFrom/authzTo it is supposed to allow multiple results. > Interestingly, it looks like slap_sasl_match isn't even used for > authzRegexp mapping any more. Something is definitely broken here. > This behavior was changed in rev 1.126 of saslauthz.c. I believe the relevant portions of that patch need to be reverted. e.g. patch -R: diff -u -r1.125 -r1.126 --- saslauthz.c 26 Apr 2004 19:47:02 -0000 1.125 +++ saslauthz.c 26 Apr 2004 20:47:08 -0000 1.126 @@ -772,14 +802,26 @@ { smatch_info *sm = o->o_callback->sc_private; - if (rs->sr_type != REP_SEARCH) return 0; + if ( rs->sr_type != REP_SEARCH ) { + if ( rs->sr_err != LDAP_SUCCESS ) { + sm->match = -1; + } + return 0; + } + + if ( sm->match == 1 ) { + sm->match = -1; + return 0; + } if (dn_match(sm->dn, &rs->sr_entry->e_nname)) { sm->match = 1; - return -1; /* short-circuit the search */ + + } else { + sm->match = -1; } - return 1; + return 0; } /* @@ -984,7 +1026,7 @@ op.o_bd->be_search( &op, &rs ); - if (sm.match) { + if (sm.match == 1) { rc = LDAP_SUCCESS; } else { rc = LDAP_INAPPROPRIATE_AUTH; -- -- 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#4744) Bug in SASL authzTo validation using an ldap:// rule
by hyc＠symas.com 11 Nov '06

11 Nov '06

ando(a)sys-net.it wrote: > sylvain(a)pilotsystems.net wrote: >> Full_Name: Sylvain Viollon >> Version: 2.3 >> OS: FreeBSD 5 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.204.228.114) >> >> >> >> I have an directory with some users in ou=people,dc=pilotsystems,dc=net branch, >> having a custom class krbUser ; and a user (cn=auth,dc=pilotsystems,dc=net) >> having the following attribute : >> >> authzTo: ldap:///ou=people,dc=pilotsystems,dc=net??sub?(objectClass=krbUser) >> >> He can successfully authenticate, but not become an user listed by the search >> (with PROXYAUTHZ). Running slapd in debug-mode I saw that he can only become the >> last user returned by the search. >> >> In source, I read the file 'servers/slapd/saslauthz.c'. The filter >> 'sasl_sc_smatch' said if the wanted user is in the search result. In this >> function, there is a test : >> >> if ( sm->match == 1 ) { >> sm->match = -1; >> return 0; >> } >> >> I have removed the line : >> >> sm->match = -1; >> >> Which make the match to fail if there is an entry in the search return after the >> good one. Like every DN have to be unique, there is no multiple solution, and >> validation would not be discarded for that. I didn't know if it's a good >> solution, but it's work. >> >> > As far as I remember, that test is intended to prevent mapping when the > search returns more than one entry. This makes perfectly sense, > otherwise a SASL identity (or an authorization identity) would be > arbitrarily mapped to one of the matching entries. So mapping is > intended to succeed if and only if exactly one identity can be resolved. That test is only supposed to prevent mapping when doing an authzRegexp mapping of a single SASL userID to a DN. When looking up authzFrom/authzTo it is supposed to allow multiple results. Interestingly, it looks like slap_sasl_match isn't even used for authzRegexp mapping any more. Something is definitely broken here. -- -- 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#4744) Bug in SASL authzTo validation using an ldap:// rule
by ando＠sys-net.it 11 Nov '06

11 Nov '06

sylvain(a)pilotsystems.net wrote: > Full_Name: Sylvain Viollon > Version: 2.3 > OS: FreeBSD 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.204.228.114) > > > > I have an directory with some users in ou=people,dc=pilotsystems,dc=net branch, > having a custom class krbUser ; and a user (cn=auth,dc=pilotsystems,dc=net) > having the following attribute : > > authzTo: ldap:///ou=people,dc=pilotsystems,dc=net??sub?(objectClass=krbUser) > > He can successfully authenticate, but not become an user listed by the search > (with PROXYAUTHZ). Running slapd in debug-mode I saw that he can only become the > last user returned by the search. > > In source, I read the file 'servers/slapd/saslauthz.c'. The filter > 'sasl_sc_smatch' said if the wanted user is in the search result. In this > function, there is a test : > > if ( sm->match == 1 ) { > sm->match = -1; > return 0; > } > > I have removed the line : > > sm->match = -1; > > Which make the match to fail if there is an entry in the search return after the > good one. Like every DN have to be unique, there is no multiple solution, and > validation would not be discarded for that. I didn't know if it's a good > solution, but it's work. > > As far as I remember, that test is intended to prevent mapping when the search returns more than one entry. This makes perfectly sense, otherwise a SASL identity (or an authorization identity) would be arbitrarily mapped to one of the matching entries. So mapping is intended to succeed if and only if exactly one identity can be resolved. If the behavior you're experiencing is consistent with the above, there is no evidence of a bug in OpenLDAP software. If it's not, please detail. Otherwise, this ITS will be closed. p. Unless 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

(ITS#4744) Bug in SASL authzTo validation using an ldap:// rule
by sylvain＠pilotsystems.net 11 Nov '06

11 Nov '06

Full_Name: Sylvain Viollon Version: 2.3 OS: FreeBSD 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.204.228.114) I have an directory with some users in ou=people,dc=pilotsystems,dc=net branch, having a custom class krbUser ; and a user (cn=auth,dc=pilotsystems,dc=net) having the following attribute : authzTo: ldap:///ou=people,dc=pilotsystems,dc=net??sub?(objectClass=krbUser) He can successfully authenticate, but not become an user listed by the search (with PROXYAUTHZ). Running slapd in debug-mode I saw that he can only become the last user returned by the search. In source, I read the file 'servers/slapd/saslauthz.c'. The filter 'sasl_sc_smatch' said if the wanted user is in the search result. In this function, there is a test : if ( sm->match == 1 ) { sm->match = -1; return 0; } I have removed the line : sm->match = -1; Which make the match to fail if there is an entry in the search return after the good one. Like every DN have to be unique, there is no multiple solution, and validation would not be discarded for that. I didn't know if it's a good solution, but it's work. Openldap 2.2 and 2.4 seems to have the same problem.

1 0

ITS#3755 strict aliasing rules
by hyc＠symas.com 11 Nov '06

11 Nov '06

Compiling current HEAD with gcc 4.1.1 make AC_CFLAGS="-g -fstrict-aliasing -O3 -Wstrict-aliasing" -j3 CC=gcc turned up a few "will break strict-aliasing rules" warnings: libldap/cyrus.c libldap/getdn.c clients/tools/ldapsearch.c servers/slapd/sasl.c I've silenced all of those. Whether the code was actually unsafe before and is safer now is anybody's guess; I was unable to get any of it to misbehave with various combinations of optimization switches. There are warnings about using the BerElementBuffer "might break strict-aliasing rules" which I've chosen to ignore. Since the memory is only actually referenced through the BerElement pointer, whether or not the contents are defined when accessing the BerElementBuffer is irrelevant. (I.e., we never access it that way, so it's moot.) -- -- 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#4742) parameter unique_attributes and unknown attribute types
by ando＠sys-net.it 10 Nov '06

10 Nov '06

michael(a)stroeder.com wrote: > It seems that slapd stops without configuration error message if unknown > attribute types are set for parameter unique_attributes (slapo-unique). It would > be nice if a descriptive message is displayed (like in other cases). > I think this occurs if debug is set to "config" or "-1". However, it would be more appropriate to log configuration errors that result in failures at "any", so that whatever logging is set they show up. For this purpose, many of the current occurrences of LDAP_DEBUG_CONFIG should be turned into (LDAP_DEBUG_CONFIG | LDAP_DEBUG_NONE), so that they show up when caught by tools with default logging (e.g. slaptest(8)), or into LDAP_DEBUG_ANY, so that they show up all times. I'd vote for the latter. Cheers, 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

(ITS#4743) ldapsearch manpage Project reference
by quanah＠stanford.edu 10 Nov '06

10 Nov '06

Full_Name: Quanah Gibson-Mount Version: 2.3.28/2.3.29 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) The ldapsearch(1) man page was sync'd for the 2.3.28 release, and inadverdently included a reference to the "Projects" file, which is a HEAD specific bit.

1 0

(ITS#4742) parameter unique_attributes and unknown attribute types
by michael＠stroeder.com 10 Nov '06

10 Nov '06

Full_Name: Michael Ströder Version: HEAD OS: SuSE Linux 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.25.247) HI! It seems that slapd stops without configuration error message if unknown attribute types are set for parameter unique_attributes (slapo-unique). It would be nice if a descriptive message is displayed (like in other cases). Ciao, Michael.

1 0

Re: (ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by hyc＠symas.com 10 Nov '06

10 Nov '06

Eric Covener wrote: > On 11/9/06, Howard Chu <hyc(a)symas.com> wrote: >> covener(a)gmail.com wrote: >> > FWIW, Another SDK I'm working with exposes a once-per-process SSL >> > initialization method, that would amount to ldap_pvt_tls_init(); >> >> A fix for this is in HEAD, please test. > > Now working for me on HEAD: > ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, /CA.pem); > ldap_set_option(NULL, LDAP_OPT_X_TLS_CERTFILE, "/cert1.pem"); > ldap_set_option(NULL, LDAP_OPT_X_TLS_KEYTFILE, "/cert1.key"); > > ld1 = ldap_init(h,p); > ldap_set_option(ld1, LDAP_OPT_X_TLS_CERTFILE, "/cert2.pem"); > ldap_set_option(ld1, LDAP_OPT_X_TLS_KEYTFILE, "/cert2.key"); > ldap_set_option(ld1, LDAP_OPT_X_NEW_CTX, &(is_server)); > > ld2 = ldap_init(h,p); > > and connections to ld1 and ld2 send the right client cert over the > wire. Hope this is a resonable API usage -- Much appreciated! > Thanks for the confirmation. The is_server flag only needs to be set non-zero if you are going to be accepting incoming TLS sessions with that context. -- -- 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#4726) ldap_pvt_tls_init not called when new CTX requested
by covener＠gmail.com 10 Nov '06

10 Nov '06

On 11/9/06, Howard Chu <hyc(a)symas.com> wrote: > covener(a)gmail.com wrote: > > FWIW, Another SDK I'm working with exposes a once-per-process SSL > > initialization method, that would amount to ldap_pvt_tls_init(); > > A fix for this is in HEAD, please test. Now working for me on HEAD: ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, /CA.pem); ldap_set_option(NULL, LDAP_OPT_X_TLS_CERTFILE, "/cert1.pem"); ldap_set_option(NULL, LDAP_OPT_X_TLS_KEYTFILE, "/cert1.key"); ld1 = ldap_init(h,p); ldap_set_option(ld1, LDAP_OPT_X_TLS_CERTFILE, "/cert2.pem"); ldap_set_option(ld1, LDAP_OPT_X_TLS_KEYTFILE, "/cert2.key"); ldap_set_option(ld1, LDAP_OPT_X_NEW_CTX, &(is_server)); ld2 = ldap_init(h,p); and connections to ld1 and ld2 send the right client cert over the wire. Hope this is a resonable API usage -- Much appreciated! -- Eric Covener covener(a)gmail.com

1 0

Re: (ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by hyc＠symas.com 09 Nov '06

09 Nov '06

covener(a)gmail.com wrote: > FWIW, Another SDK I'm working with exposes a once-per-process SSL > initialization method, that would amount to ldap_pvt_tls_init(); A fix for this is in HEAD, please test. -- -- 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#4726) ldap_pvt_tls_init not called when new CTX requested
by covener＠gmail.com 09 Nov '06

09 Nov '06

FWIW, Another SDK I'm working with exposes a once-per-process SSL initialization method, that would amount to ldap_pvt_tls_init();

1 0

(ITS#4739)
by hardimankevin＠yahoo.com 09 Nov '06

09 Nov '06

--0-1558012606-1163097706=:73509 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Apologies for the breach of etiqette. Will change the backend.=0A=0A -k= ph=0A=0A=0A=0A=0A=0A=0A =0A________________________________________________= ____________________________________=0ADo you Yahoo!?=0AEveryone is raving = about the all-new Yahoo! Mail beta.=0Ahttp://new.mail.yahoo.com --0-1558012606-1163097706=:73509 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable <html><head><style type=3D"text/css"></style></he= ad><body><div style=3D"font-family:arial, helvetica, sans-serif;font-size:1= 0pt"><div>Apologies for the breach of etiqette.  Will change the backe= nd.     -kph </div></div> =0A=0A=0A<hr = size=3D1>Everyone is raving about <a href=3D"http://us.rd.yahoo.com/evt=3D4= 2297/*http://advision.webevents.yahoo.com/mailbeta">the all-new Yahoo! Mail= beta.</a></body></html> --0-1558012606-1163097706=:73509--

1 0

Re: (ITS#4741) ppolicy.c improperly discards return value of check_password() function
by hyc＠symas.com 09 Nov '06

09 Nov '06

lsherida(a)nccs.nasa.gov wrote: > Full_Name: Lee Sheridan > Version: 2.3.27 > OS: Debian GNU/Linux (etch) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.168.13.7) > > > In servers/slapd/overlays/ppolicy.c, check_password_quality function, at > line 530, the value of the 'ok' variable is discarded by unconditionally > assigning it the value LDAP_SUCCESS. > > The variable is the return code of the user-defined check_password() function, > which is assigned at line 522. The next if-then-else block is checking to > see if the module reported an error, at which point 'ok' would be assigned > LDAP_OTHER regardless of what check_password() returned. A superfluous else > block appears after this check, assigning 'ok' to LDAP_SUCCESS. > > It works fine for me if I remove the else block. > > Thanks, A fix has been committed to CVS HEAD. -- -- 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

[Fwd: Re: (ITS#4739) Server crashes every time alias is dereferenced]
by hyc＠symas.com 09 Nov '06

09 Nov '06

This is a multi-part message in MIME format. --------------080602030800020000070003 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit This is the info Kevin sent before. aliases are known to work incorrectly in back-ldbm. back-ldbm has been deprecated since OpenLDAP 2.2 and has been deleted from the source tree for OpenLDAP 2.4. As such, I don't see us taking any action on this bug report. Use back-bdb or back-hdb instead. -------- Original Message -------- Subject: Re: (ITS#4739) Server crashes every time alias is dereferenced Date: Wed, 8 Nov 2006 22:09:51 -0800 (PST) From: Kevin Hardiman <hardimankevin(a)yahoo.com> To: Howard Chu <hyc(a)symas.com> Howard, To answer your initial questions: 1. The aliased entry does exist 2. The backined is ldbm 3. Attached is a sanitized slapd.conf 4. Attached is a sanitized ldif export Here's the output from running slapd (sanitized for sensitive information) without forking (-d 1): > >> dnPrettyNormal: <ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com> <<< dnPrettyNormal: <ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com>, <ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: => ldbm_back_search dn2entry_r: dn: "ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" => dn2id( "ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" ) ====> cache_find_entry_ndn2id("ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com"): 16378 (1 tries) <= dn2id 16378 (in cache) => id2entry_r( 16378 ) ====> cache_find_entry_id( 16378 ) "ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com" (found) (1 tries) <= id2entry_r( 16378 ) 0x82d2068 (cache) search_candidates: base="ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" s=2 d=3 => filter_candidates => list_candidates 0xa0 => filter_candidates => dn2idl( "@ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" ) => ldbm_cache_open( "dn2id.dbb", 73, 600 ) <= ldbm_cache_open (cache 0) <= filter_candidates 2 => filter_candidates => list_candidates 0xa1 => filter_candidates => equality_candidates => ldbm_cache_open( "objectClass.dbb", 73, 600 ) <= ldbm_cache_open (cache 3) => key_read <= index_read 1 candidates <= equality_candidates 1 <= filter_candidates 1 => filter_candidates => equality_candidates => ldbm_cache_open( "objectClass.dbb", 73, 600 ) <= ldbm_cache_open (cache 3) => key_read <= index_read 0 candidates <= equality_candidates NULL <= equality_candidates 0 <= filter_candidates 0 idl_free: called with NULL pointer => filter_candidates => list_candidates 0xa0 => filter_candidates => equality_candidates => ldbm_cache_open( "objectClass.dbb", 73, 600 ) <= ldbm_cache_open (cache 3) => key_read <= index_read 4 candidates <= equality_candidates 4 <= filter_candidates 4 => filter_candidates => equality_candidates => ldbm_cache_open( "uid.dbb", 73, 600 ) <= ldbm_cache_open (cache 4) => key_read <= index_read 0 candidates <= equality_candidates NULL <= equality_candidates 0 <= filter_candidates 0 <= list_candidates NULL <= filter_candidates 0 idl_free: called with NULL pointer <= list_candidates 1 <= filter_candidates 1 <= list_candidates 1 <= filter_candidates 1 ====> cache_return_entry_r( 16378 ): returned (0) => id2entry_r( 16400 ) ====> cache_find_entry_id( 16400 ) "uid=test,ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com" (found) (1 tries) <= id2entry_r( 16400 ) 0x82d5580 (cache) dn2entry_r: dn: "ÿÿÐuhH_øP" => dn2id( "ÿÿÐuhH_øP" ) => ldbm_cache_open( "dn2id.dbb", 73, 600 ) <= ldbm_cache_open (cache 0) <= dn2id NOID slapd: dn.c:1148: dnParent: Assertion `( ( ( ( (p[ 0 ]) >= 'a' && (p[ 0 ]) <= 'z' ) || ( (p[ 0 ]) >= 'A' && (p[ 0 ]) <= 'Z' ) ) ) || ( ( (p[ 0 ]) >= '0' && (p[ 0 ]) <= '9' ) ) )' failed. Aborted Let me know if you need anything else. Regards, Kevin Hardiman ----- Original Message ---- From: Howard Chu <hyc(a)symas.com> To: hardimankevin(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Wednesday, November 8, 2006 9:45:27 PM Subject: Re: (ITS#4739) Server crashes every time alias is dereferenced hardimankevin(a)yahoo.com wrote: > Full_Name: Kevin Hardiman > Version: 2.3.27 > OS: Linux (Mandriva 2007) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.90.130.182) > > > Using the very simple alias below, OpenLDAP will crash every time it is > dereferenced: > > dn: uid=test,ou=Users,ou=bladiant,ou=smb,ou=Core Services,dc=example,dc=com > objectClass: alias > objectclass: extensibleObject > uid: test > aliasedObjectName: uid=test,ou=Users,dc=example,dc=com > > This error has been experience with OpenLDAP releases 2.3.6 and 2.3.27, both in > the form of provided Mandriva packages. I also have seen a number of references > to this error in previous releases, with no explicit fix. Please advise. Well, considering that no one has reported any such problem during the whole time releases 2.3.6-2.3.27 were published, it's no surprise that there has been no fix yet. There's not enough information here to reproduce the bug. What backend are you using, what other entries are in the database? In particular, does "uid=test,ou=Users,dc=example,dc=com" exist? You should provide a sample slapd.conf and minimal LDIF needed to reproduce the error. -- -- 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/ ------------------------------------------------------------------------ Sponsored Link $200,000 mortgage for $660/mo - 30/15 yr fixed, reduce debt, home equity - Click now for info <http://www.ratemarketplace.com/forms/form.jsp?ADEL=Os4fVJ19lSwzAOc/zMz/CYLq…> -- -- 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/ --------------080602030800020000070003 Content-Type: application/octet-stream; name="slapd.conf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slapd.conf" aW5jbHVkZQkvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9jb3JlLnNjaGVtYQppbmNsdWRl CS91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2Nvc2luZS5zY2hlbWEKaW5jbHVkZQkvdXNy L3NoYXJlL29wZW5sZGFwL3NjaGVtYS9jb3JiYS5zY2hlbWEgCmluY2x1ZGUJL3Vzci9zaGFy ZS9vcGVubGRhcC9zY2hlbWEvaW5ldG9yZ3BlcnNvbi5zY2hlbWEKaW5jbHVkZQkvdXNyL3No YXJlL29wZW5sZGFwL3NjaGVtYS9qYXZhLnNjaGVtYSAKaW5jbHVkZQkvdXNyL3NoYXJlL29w ZW5sZGFwL3NjaGVtYS9rcmI1LWtkYy5zY2hlbWEKaW5jbHVkZSAvdXNyL3NoYXJlL29wZW5s ZGFwL3NjaGVtYS9rZXJiZXJvc29iamVjdC5zY2hlbWEKaW5jbHVkZQkvdXNyL3NoYXJlL29w ZW5sZGFwL3NjaGVtYS9taXNjLnNjaGVtYQppbmNsdWRlCS91c3Ivc2hhcmUvb3BlbmxkYXAv c2NoZW1hL25pcy5zY2hlbWEKaW5jbHVkZQkvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9v cGVubGRhcC5zY2hlbWEgCmluY2x1ZGUgL3Vzci9zaGFyZS9vcGVubGRhcC9zY2hlbWEvYXV0 b2ZzLnNjaGVtYQppbmNsdWRlIC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL3NhbWJhLnNj aGVtYQppbmNsdWRlIC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2tvbGFiLnNjaGVtYQpp bmNsdWRlIC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2V2b2x1dGlvbnBlcnNvbi5zY2hl bWEKaW5jbHVkZSAvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9jYWxlbmRhci5zY2hlbWEK aW5jbHVkZSAvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9zdWRvLnNjaGVtYQppbmNsdWRl IC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2Ruc3pvbmUuc2NoZW1hCmluY2x1ZGUgL3Vz ci9zaGFyZS9vcGVubGRhcC9zY2hlbWEvZGhjcC5zY2hlbWEKaW5jbHVkZQkvZXRjL29wZW5s ZGFwL3NjaGVtYS9sb2NhbC5zY2hlbWEKaW5jbHVkZSAvdXNyL3NoYXJlL29wZW5sZGFwL3Nj aGVtYS9tb3ppbGxhQWJQZXJzb25BbHBoYS5zY2hlbWEKaW5jbHVkZSAJL2V0Yy9vcGVubGRh cC9zbGFwZC5hY2Nlc3MuY29uZgoKYWNjZXNzIHRvIGRuLnN1YnRyZWU9ImRjPWV4YW1wbGUs ZGM9Y29tIgogICAgICAgIGJ5IGdyb3VwPSJjbj1SZXBsaWNhdG9yLG91PUdyb3VwLGRjPWV4 YW1wbGUsZGM9Y29tIgogICAgICAgIGJ5IHVzZXJzIHJlYWQKICAgICAgICBieSBhbm9ueW1v dXMgcmVhZAoKbGltaXRzIGdyb3VwPSJjbj1SZXBsaWNhdG9yLG91PUdyb3VwLGRjPWV4YW1w bGUsZGM9Y29tIgogc2l6ZT11bmxpbWl0ZWQKIHRpbWU9dW5saW1pdGVkCnBpZGZpbGUJCS92 YXIvcnVuL2xkYXAvc2xhcGQucGlkCmFyZ3NmaWxlCS92YXIvcnVuL2xkYXAvc2xhcGQuYXJn cwptb2R1bGVwYXRoCS91c3IvbGliL29wZW5sZGFwClRMU1JhbmRGaWxlICAgICAgICAgICAg L2Rldi9yYW5kb20KVExTQ2lwaGVyU3VpdGUgICAgICAgICBISUdIOk1FRElVTTorU1NMdjIK VExTQ2VydGlmaWNhdGVGaWxlICAgICAgL2V0Yy9zc2wvb3BlbmxkYXAvbGRhcGNlcnQucGVt ClRMU0NlcnRpZmljYXRlS2V5RmlsZSAgIC9ldGMvc3NsL29wZW5sZGFwL2xkYXBrZXkucGVt ClRMU0NBQ2VydGlmaWNhdGVQYXRoICAgL2V0Yy9zc2wvb3BlbmxkYXAvClRMU0NBQ2VydGlm aWNhdGVGaWxlICAgIC9ldGMvc3NsL29wZW5sZGFwL2NhY2VydC5wZW0KVExTVmVyaWZ5Q2xp ZW50IHRyeSAjIChbbmV2ZXJdfGFsbG93fHRyeXxkZW1hbmQpCmxvZ2xldmVsIDI2OAphbGxv dyBiaW5kX3YyCnNhc2wtc2VjcHJvcHMgbm9uZQpkYXRhYmFzZQlsZGJtCnN1ZmZpeAkJImRj PWJsYWRpYW50LGRjPWNvbSIKcm9vdGRuCQkiY249S2V2aW4gSGFyZGltYW4sb3U9UGVvcGxl LGRjPWV4YW1wbGUsZGM9Y29tIgpsYXN0bW9kCQlvbgpkaXJlY3RvcnkJL3Zhci9saWIvbGRh cApjaGVja3BvaW50IDI1NiA1CmluZGV4CW9iamVjdENsYXNzLHVpZCx1aWROdW1iZXIsZ2lk TnVtYmVyLG1lbWJlcnVpZAllcQppbmRleAljbixtYWlsLHN1cm5hbWUsZ2l2ZW5uYW1lCQll cSxzdWJpbml0aWFsCiAK --------------080602030800020000070003 Content-Type: application/octet-stream; name="minimal_export.ldif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="minimal_export.ldif" ZG46IG91PVVzZXJzLCBkYz1leGFtcGxlLGRjPWNvbQpvdTogVXNlcnMKb2JqZWN0Q2xhc3M6 IG9yZ2FuaXphdGlvbmFsVW5pdAoKZG46IHVpZD10ZXN0LCBvdT1Vc2VycywgZGM9ZXhhbXBs ZSxkYz1jb20Kc2FtYmFQcmltYXJ5R3JvdXBTSUQ6IFhYWFgKc2FtYmFMTVBhc3N3b3JkOiBY WFhYCmRpc3BsYXlOYW1lOiBLZXZpbiBIYXJkaW1hbgpvYmplY3RDbGFzczogdG9wCm9iamVj dENsYXNzOiBpbmV0T3JnUGVyc29uCm9iamVjdENsYXNzOiBwb3NpeEFjY291bnQKb2JqZWN0 Q2xhc3M6IHNoYWRvd0FjY291bnQKb2JqZWN0Q2xhc3M6IHNhbWJhU2FtQWNjb3VudAp1c2Vy UGFzc3dvcmQ6OiBYWFhYCnNhbWJhTG9nb25UaW1lOiAwCnVpZE51bWJlcjogNTAwCnVpZDog dGVzdApjbjogdGVzdApzYW1iYUxvZ29mZlRpbWU6IDIxNDc0ODM2NDcKc2FtYmFQd2RMYXN0 U2V0OiAxMTYxOTIzMzcwCmxvZ2luU2hlbGw6IC9iaW4vYmFzaApzYW1iYUFjY3RGbGFnczog W1VdCmdpZE51bWJlcjogMTAwCnNhbWJhUHdkTXVzdENoYW5nZTogMTE2NTgxMTM3MApzYW1i YVNJRDogWFhYCnNhbWJhUHdkQ2FuQ2hhbmdlOiAwCnNhbWJhTlRQYXNzd29yZDogWFhYCmdl Y29zOiBLZXZpbiBIYXJkaW1hbgpkZXNjcmlwdGlvbjogS2V2aW4gSGFyZGltYW4KaG9tZURp cmVjdG9yeTogL2hvbWUvdGVzdApzYW1iYUtpY2tvZmZUaW1lOiAyMTQ3NDgzNjQ3CnNuOiBI YXJkaW1hbgoKZG46IG91PUNvcmUgU2VydmljZXMsIGRjPWV4YW1wbGUsZGM9Y29tCm91OiBD b3JlIFNlcnZpY2VzCm9iamVjdENsYXNzOiB0b3AKb2JqZWN0Q2xhc3M6IG9yZ2FuaXphdGlv bmFsVW5pdAoKZG46IG91PXNtYiwgb3U9Q29yZSBTZXJ2aWNlcywgZGM9ZXhhbXBsZSxkYz1j b20Kb3U6IHNtYgpvYmplY3RDbGFzczogdG9wCm9iamVjdENsYXNzOiBvcmdhbml6YXRpb25h bFVuaXQKCmRuOiBvdT1leGFtcGxlLG91PXNtYiwgb3U9Q29yZSBTZXJ2aWNlcywgZGM9ZXhh bXBsZSxkYz1jb20Kb3U6IGV4YW1wbGUKb2JqZWN0Q2xhc3M6IHRvcApvYmplY3RDbGFzczog b3JnYW5pemF0aW9uYWxVbml0Cgpkbjogb3U9VXNlcnMsb3U9ZXhhbXBsZSxvdT1zbWIsIG91 PUNvcmUgU2VydmljZXMsIGRjPWV4YW1wbGUsZGM9Y29tCm91OiBVc2VycwpvYmplY3RDbGFz czogdG9wCm9iamVjdENsYXNzOiBvcmdhbml6YXRpb25hbFVuaXQKCmRuOiB1aWQ9dGVzdCxv dT1Vc2VycyxvdT1leGFtcGxlLG91PXNtYixvdT1Db3JlIFNlcnZpY2VzLGRjPWV4YW1wbGUs ZGM9Y29tCm9iamVjdENsYXNzOiBhbGlhcwpvYmplY3RjbGFzczogZXh0ZW5zaWJsZU9iamVj dAp1aWQ6IHRlc3QKYWxpYXNlZE9iamVjdE5hbWU6IHVpZD10ZXN0LG91PVVzZXJzLGRjPWV4 YW1wbGUsZGM9Y29tCg== --------------080602030800020000070003--

1 0

Re: (ITS#4741) ppolicy.c improperly discards return value of check_password() function
by quanah＠stanford.edu 09 Nov '06

09 Nov '06

--On Thursday, November 09, 2006 2:20 AM +0000 lsherida(a)nccs.nasa.gov wrote: > Full_Name: Lee Sheridan > Version: 2.3.27 > OS: Debian GNU/Linux (etch) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.168.13.7) > > > In servers/slapd/overlays/ppolicy.c, check_password_quality function, at > line 530, the value of the 'ok' variable is discarded by unconditionally > assigning it the value LDAP_SUCCESS. > > The variable is the return code of the user-defined check_password() > function, which is assigned at line 522. The next if-then-else block is > checking to see if the module reported an error, at which point 'ok' > would be assigned LDAP_OTHER regardless of what check_password() > returned. A superfluous else block appears after this check, assigning > 'ok' to LDAP_SUCCESS. > > It works fine for me if I remove the else block. Howard checked in a fix to HEAD for this last night, please test. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4739) Server crashes every time alias is dereferenced
by quanah＠stanford.edu 09 Nov '06

09 Nov '06

--On Thursday, November 09, 2006 5:08 PM +0000 hardimankevin(a)yahoo.com wrote: > --0-1753053770-1163092074=:90949 > Content-Type: text/plain; charset=ascii > Content-Transfer-Encoding: quoted-printable > > Buchan,=0A=0ANot sure what to say - I can reproduce this error with the > Man= driva packages and from source (which leads me to believe it has > nothing to= do with the packaging) with a 100% rate. I had sent Howard > Chu an email l= ast night with much more detail; if you'd like me to > forward that I will.= =0A=0A -kph=0A=0A=0A----- Original Message > You should send responses with more detail to the ITS, not to individual people. This allows all developers and other involved to have the full information. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4739) Server crashes every time alias is dereferenced
by hardimankevin＠yahoo.com 09 Nov '06

09 Nov '06

--0-1753053770-1163092074=:90949 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Buchan,=0A=0ANot sure what to say - I can reproduce this error with the Man= driva packages and from source (which leads me to believe it has nothing to= do with the packaging) with a 100% rate. I had sent Howard Chu an email l= ast night with much more detail; if you'd like me to forward that I will.= =0A=0A -kph=0A=0A=0A----- Original Message ----=0AFrom: Buchan Milne <bg= milne(a)staff.telkomsa.net>=0ATo: hardimankevin(a)yahoo.com=0ACc: openldap-its@= openldap.org=0ASent: Thursday, November 9, 2006 11:07:10 AM=0ASubject: Re: = (ITS#4739) Server crashes every time alias is dereferenced=0A=0AOn Wednesda= y 08 November 2006 21:18, hardimankevin(a)yahoo.com wrote:=0A> Full_Name: Kev= in Hardiman=0A> Version: 2.3.27=0A> OS: Linux (Mandriva 2007)=0A> URL: ftp:= //ftp.openldap.org/incoming/=0A> Submission from: (NULL) (24.90.130.182)=0A= >=0A>=0A> Using the very simple alias below, OpenLDAP will crash every time= it is=0A> dereferenced:=0A>=0A> dn: uid=3Dtest,ou=3DUsers,ou=3Dbladiant,ou= =3Dsmb,ou=3DCore Services,dc=3Dexample,dc=3Dcom=0A> objectClass: alias=0A> = objectclass: extensibleObject=0A> uid: test=0A> aliasedObjectName: uid=3Dte= st,ou=3DUsers,dc=3Dexample,dc=3Dcom=0A>=0A> This error has been experience = with OpenLDAP releases 2.3.6 and 2.3.27,=0A> both in the form of provided M= andriva packages. I also have seen a number=0A> of references to this erro= r in previous releases, with no explicit fix. =0A> Please advise.=0A=0A=0AC= an't reproduce:=0A=0A$ ldapsearch -h localhost -LLL -s children -a never -= x -b "ou=3DTest =0AAliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom"=0Adn: uid=3D= bgmilne,ou=3DTest Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom=0AobjectClass:= alias=0AobjectClass: extensibleObject=0Auid: bgmilne=0AaliasedObjectName: = uid=3Dbgmilne,ou=3DPeople,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom=0A=0A$ ldapsea= rch -h localhost -LLL -s children -a always -x -b "ou=3DTest =0AAliases,dc= =3Dranger,dc=3Ddnsalias,dc=3Dcom" objectclass=0Adn: uid=3Dbgmilne,ou=3DPeop= le,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom=0AobjectClass: mailRecipient=0Aobject= Class: person=0AobjectClass: organizationalPerson=0AobjectClass: inetOrgPer= son=0AobjectClass: posixAccount=0AobjectClass: top=0AobjectClass: kerberosS= ecurityObject=0AobjectClass: shadowAccount=0AobjectClass: sambaSamAccount= =0A=0A$ rpm -q openldap-servers=0Aopenldap-servers-2.3.27-1mdv2007.0=0A=0A$= rpm -q openldap-servers --qf "%{PACKAGER}\n"=0ABuchan Milne <bgmilne@mandr= iva.org>=0A=0A=0ARegards,=0ABuchan=0A=0A-- =0ABuchan Milne=0AISP Systems Sp= ecialist - Monitoring/Authentication Team Leader=0AB.Eng,RHCE(8030047890107= 97),LPIC-2(LPI000074592)=0A=0A=0A=0A=0A=0A=0A=0A =0A_______________________= _____________________________________________________________=0ADo you Yaho= o!?=0AEveryone is raving about the all-new Yahoo! Mail beta.=0Ahttp://new.m= ail.yahoo.com --0-1753053770-1163092074=:90949 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable <html><head><style type=3D"text/css"></style></he= ad><body><div style=3D"font-family:arial, helvetica, sans-serif;font-size:1= 0pt"><div style=3D"font-family: arial,helvetica,sans-serif; font-size: 10pt= ;">Buchan, Not sure what to say - I can reproduce this error with th= e Mandriva packages and from source (which leads me to believe it has nothi= ng to do with the packaging) with a 100% rate.  I had sent Howard Chu = an email last night with much more detail; if you'd like me to forward that= I will.     -kph <div style=3D"font-famil= y: times new roman,new york,times,serif; font-size: 12pt;">----- Original M= essage ---- From: Buchan Milne <bgmilne(a)staff.telkomsa.net> To:= hardimankevin(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Thursday= , November 9, 2006 11:07:10 AM Subject: Re: (ITS#4739) Server crashes ev= ery time alias is dereferenced <div>On Wednesday 08 November 2006 21= :18, hardimankevin(a)yahoo.com wrote: > Full_Name: Kevin Hardiman > V= ersion: 2.3.27 > OS: Linux (Mandriva 2007) > URL: ftp://ftp.ope= nldap.org/incoming/ > Submission from: (NULL) (24.90.130.182) >= > > Using the very simple alias below, OpenLDAP will crash eve= ry time it is > dereferenced: > > dn: uid=3Dtest,ou=3DUse= rs,ou=3Dbladiant,ou=3Dsmb,ou=3DCore Services,dc=3Dexample,dc=3Dcom > = objectClass: alias > objectclass: extensibleObject > uid: test<= br>> aliasedObjectName: uid=3Dtest,ou=3DUsers,dc=3Dexample,dc=3Dcom &= gt; > This error has been experience with OpenLDAP releases 2.3.6 and= 2.3.27, > both in the form of provided Mandriva packages. &nbsp= ;I also have seen a number > of references to this error in previous = releases, with no explicit fix. > Please advise. Can't re= produce: $ ldapsearch -h localhost -LLL -s children -a never &n= bsp;-x -b "ou=3DTest Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom" dn: uid=3Dbgmilne,ou=3D= Test Aliases,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom objectClass: alias ob= jectClass: extensibleObject uid: bgmilne aliasedObjectName: uid=3Dbgm= ilne,ou=3DPeople,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom $ ldapsearch -h = localhost -LLL -s children -a always  -x -b "ou=3DTest Aliase= s,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom" objectclass dn: uid=3Dbgmilne,ou= =3DPeople,dc=3Dranger,dc=3Ddnsalias,dc=3Dcom objectClass: mailRecipient<= br>objectClass: person objectClass: organizationalPerson objectClass:= inetOrgPerson objectClass: posixAccount objectClass: top objectCl= ass: kerberosSecurityObject objectClass: shadowAccount objectClass: s= ambaSamAccount $ rpm -q openldap-servers openldap-servers-2.3.27-= 1mdv2007.0 $ rpm -q openldap-servers --qf "%{PACKAGER}\n" Buchan = Milne <bgmilne(a)mandriva.org> Regards, Buchan -- = Buchan Milne ISP Systems Specialist - Monitoring/Authentication Team Leader B.Eng,RHCE(803004789010797),LPIC-= 2(LPI000074592) </div></div> </div></div> =0A=0A<hr size=3D1>Every= one is raving about <a href=3D"http://us.rd.yahoo.com/evt=3D45083/*http://a= dvision.webevents.yahoo.com/mailbeta">the all-new Yahoo! Mail beta.</a></bo= dy></html> --0-1753053770-1163092074=:90949--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs