openldap-bugs September 2008

openldap-bugs@openldap.org

39 participants
206 discussions

(ITS#5691) Re: malloc without check
by ando＠sys-net.it 09 Sep '08

09 Sep '08

Actually, I see plenty of places where it occurs. I vaguely recall that malloc used to be #defined as ch_malloc within slapd, although I believe it is no longer. In any case, I'm in favor of avoiding those redefinitions, for the sake of clarity. The correct solution should be to replace them with ch_malloc() (same for other memory-related functions, like calloc(), realloc(), strdup() and free(), although the latter is not strictly needed). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5692) Re: literal constant 8192 used instead of SLAP_LDAPDN_MAXLEN
by ando＠sys-net.it 09 Sep '08

09 Sep '08

In none of the files you indicated the buffer size 8192 is used for a DN, so I see no reason for hijacking SLAP_LDAPDN_MAXLEN for that purpose. It might be good practice to define one or more macros and consistently use them, although in the specific cases there is no repeated use of the value, nor specific consistency constraints for the use of that value. With respect to your second question, OpenLDAP never relies on SLAP_LDAPDN_MAXLEN stability in terms of buffer access; since that macro is local to slapd, if it changes the whole slapd will see it. The only issue could be with redefinition of the macro across module compilation, if you use dynamic modules. Also in that case things shouldn't be critical, as slapd never relies on that macro for accessing buffers, but rather on actual buffer size. The only potentia issue I see is with spurious syntax errors if a module with larger SLAP_LDAPDN_MAXLEN calls a DN-related validation/normalization function passing a DN whose length is larger than the value of SLAP_LDAPDN_MAXLEN slapd was built with. No buffer overflow risk, though; at most, DoS on uncommonly long DNs. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5693) [enhancement] extension of slapo-translucent filtering approach
by ando＠sys-net.it 09 Sep '08

09 Sep '08

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I see a few potential issues in current slapo-translucent(5) filtering approach: - if an attribute is marked as local, it will not be used to filter entries on the remote server; however, that attribute might exist in entries on the remote server, resulting in inconsistent search results - the same is also true in the reverse case in those cases, it might be helpful to let the same attribute be listed as local *and* remote, acting accordingly. Also, there is no way to indicate that some attributes are local and *all the others* are remote (and viceversa); it is suggested to allow "*" (and "+"?), as well as "1.1" to indicate no attributes. Wildcards would take effect unless attribute specifications are present. I don't know, right now, how easy it would be to implement those enhancements; I'm just noting them here as a reminder for a feature request. p.

1 0

Re: (ITS#5665) slapd crashing with slapo-pcache when using attrset "*"
by toby＠inf.ed.ac.uk 09 Sep '08

09 Sep '08

Hi again, I haven't been able to reproduce the problem since patching, so I consider it fixed.... Many thanks Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

(ITS#5692) literal constant 8192 used instead of SLAP_LDAPDN_MAXLEN
by andreas.moroder＠gmx.net 09 Sep '08

09 Sep '08

Full_Name: Andreas Moroder Version: 2.4.11 OS: Suse Linux 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.47.3.213) Hello, in /servers/slapd/bconfig.c /libraries/libldap_r/tls.c /libraries/libldap_r/tls.c ./libraries/liblber/stdio.c /libraries/liblunicode/ucdata/ucgendat.c /contrib/slapd-modules/lastmod/lastmod.c the literal value 8192 is used for array sizes instead of SLAP_LDAPDN_MAXLEN 8192 defined in /servers/slapd/slap.h I think this could become a problem if SLAP_LDAPDN_MAXLEN grows in a future release. A question from a newbie: What happens in a mixed environment with a never version with bigger SLAP_LDAPDN_MAXLEN that replicates his entries to a version with SLAP_LDAPDN_MAXLEN at 8192 ? Isn't it wrong not to check for a buffer owerflow when strings are concantenated and suppose that the data we use does not exceed the limit ? Bye Andreas

1 0

(ITS#5691) malloc withou check
by andreas.moroder＠gmx.net 09 Sep '08

09 Sep '08

Full_Name: Andreas Moroder Version: 2.4.11 OS: Suse Linux 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.47.3.213) Hello, in servers/slapd/add.c int the function slap_entry2mods() malloc() is called three times and the result is not checked against NULL. Bye Andreas

1 0

Re: (ITS#5690) cn=config cannot be rootdn
by ando＠sys-net.it 09 Sep '08

09 Sep '08

quanah(a)zimbra.com wrote: > In OpenLDAP 2.3, it was possible to set the rootdn of the main database to be > cn=config. This no longer works in OpenLDAP 2.4, but seems like it should be > valid to me. ... > cn=config is *clearly* under "" No, cn=config is *clearly* under cn=config, which comes earlier than "". As such, auth'ing as cn=config will be intercepted by back-config, hence the config error. > and changing it to "cn=config,dc=junk" works. > So it's specific to the term "cn=config". Changing it to "cn=joe" works just > fine. It also doesn't seem to care that I use "cn=config" with back-monitor... But then you don't need to set rootpw. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5656) Bind operations with translucent overlay
by ando＠sys-net.it 09 Sep '08

09 Sep '08

mateusz.kijowski(a)gmail.com wrote: > Full_Name: Mateusz Kijowski > Version: 2.3.43 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.126.222.22) > > > In some use scenarios, it is useful if the translucent overlay does not forward > bind operation requests to the remote server when there are values for > userPassword attribute in the local database. It would be nice if this could be > enabled or disabled by a configuration option. For consistency, enabling this > behavior should also affect the PASSMOD extended operation to modify the local > value of userPassword. The local bind feature has been added to HEAD; please test. As for the passmod feature, that requires a little bit more. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5690) cn=config cannot be rootdn
by quanah＠zimbra.com 08 Sep '08

08 Sep '08

Full_Name: Quanah Gibson-Mount Version: RE24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) In OpenLDAP 2.3, it was possible to set the rootdn of the main database to be cn=config. This no longer works in OpenLDAP 2.4, but seems like it should be valid to me. Example config: include /opt/zimbra/openldap-2.4.12/etc/openldap/schema/core.schema include "/opt/zimbra/openldap-2.4.12/etc/openldap/schema/cosine.schema" include "/opt/zimbra/openldap-2.4.12/etc/openldap/schema/inetorgperson.schema" pidfile /opt/zimbra/openldap-2.4.12/var/run/slapd.pid argsfile /opt/zimbra/openldap-2.4.12/var/run/slapd.args modulepath /opt/zimbra/openldap-2.4.12/libexec/openldap moduleload back_hdb.la moduleload back_monitor.la moduleload syncprov.la moduleload accesslog.la database config rootpw secret database monitor rootdn "cn=config" access to dn.children="cn=monitor" by * read database hdb suffix cn=accesslog directory /opt/zimbra/data/openldap/accesslog/db rootdn cn=accesslog index default eq index entryCSN index objectClass index reqEnd index reqResult index reqStart access to dn.subtree="cn=accesslog" by dn.exact="cn=config" read by dn.exact="uid=zmreplica,cn=admins,cn=zimbra" read # Checkpoint the database to prevent transaction loss in unclean shutdowns, and speed up slapd shutdowns. checkpoint 64 5 cachesize 10000 timelimit unlimited sizelimit unlimited overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE database hdb suffix "" rootdn "cn=config" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /opt/zimbra/data/openldap/db # Indices to maintain index objectClass eq index cn pres,eq,sub index displayName pres,eq,sub index sn pres,eq,sub index gn pres,eq,sub # recommended for replication index entryUUID eq index entryCSN eq sizelimit unlimited timelimit unlimited overlay syncprov syncprov-checkpoint 20 10 syncprov-sessionlog 500 overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+00:00 Slaptest fails with: line 74 (suffix "") >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> line 75 (rootdn "cn=config") >>> dnPrettyNormal: <cn=config> <<< dnPrettyNormal: <cn=config>, <cn=config> line 79 (rootpw ***) /opt/zimbra/openldap-2.4.12/etc/openldap/slapd.conf: line 79: <rootpw> can only be set when rootdn is under suffix slaptest: bad configuration file! cn=config is *clearly* under "", and changing it to "cn=config,dc=junk" works. So it's specific to the term "cn=config". Changing it to "cn=joe" works just fine. It also doesn't seem to care that I use "cn=config" with back-monitor...

1 0

Re: (ITS#5679) Translucent search
by ando＠sys-net.it 08 Sep '08

08 Sep '08

Julien Garnier wrote: > Pierangelo Masarati a écrit : >> Should now be fixed in HEAD; please test and report. >> >> p. > > I've just install head : > @(#) $OpenLDAP: slapd 2.X (Sep 8 2008 13:30:44) $ > > Seems to be OK, I only retrieve my 2 users > What was the problem ? In your specific case (a "liberal" local filter and a strict remote filter ANDed) the original filter was not applied to the entire entry, after merging the local and remote parts. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

← Newer
1
...
11
12
13
14
15
16
17
...
21
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2008