- openldap-bugs - openldap.org

(ITS#5760) attribute hiding in rwm overlay
by brett.maxfield＠gmail.com 20 Oct '08

20 Oct '08

Full_Name: Brett Maxfield Version: 2.4.12 release OS: Solaris 5.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.18.108.167) There is a bug that stops rwm-map being used to hide attributes, eg : database ldap suffix "c=AU" uri "ldap://<parent ip>:<parent port>/c=AU" overlay rwm lastmod off # attribute maps (ok except for final "rwm-map attribute *" map) rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute mail * rwm-map attribute c * rwm-map attribute o * rwm-map attribute ou * # does not like this, it stops any entries being returned #rwm-map attribute * # objectclass maps (ok) rwm-map objectclass top * rwm-map objectclass country * rwm-map objectclass organization * rwm-map objectclass organizationalRole * rwm-map objectclass organizationalPerson * rwm-map objectclass organizationalUnit * rwm-map objectclass * Comment from the openlda-software list.. > I am trying to setup a ldap backend which is a filtered view of > another larger parent directory, with respect to exposing fewer object > classes and attributes. > > The intent is to present a simpler view of the larger directory, and > the config below works, except for when i uncomment the line > containing "rwm-map attribute *", to hide the attributes i do not want > visible, but after that it stops returning any entries at all for any > query. So may be there is some important openldap attribute i am > nuking ? Yes, I fear that's hiding the objectClass attribute, which is required for internal operations. On the other hand, you can't simply tell back-ldap to preserve that attribute, because mapping objectClass is not allowed. I suggest you file an ITS so that this problem can be fixed. p. Ing. Pierangelo Masarati OpenLDAP Core Team

1 0

Re: (ITS#5755) Schema file not always converted to LDIF and slapdwon't restart
by hyc＠symas.com 20 Oct '08

20 Oct '08

h.b.furuseth(a)usit.uio.no wrote: > I wrote: >> Possibly that should wait for OpenLDAP 2.5 though, and just log a >> warning for now. > > ...though -f file -F dir should fail, of course. Splitting these two behaviors isn't possible. The same config_build_entry() function is called in both cases; once the error is detected and config_build_entry() fails, the startup will fail. Remember that the full cn=config tree is always assembled in memory, even if you don't use a persistent copy in the filesystem. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5759) whitespace vs white space
by quanah＠OpenLDAP.org 20 Oct '08

20 Oct '08

Full_Name: Quanah Gibson-Mount Version: HEAD OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) I noticed that the term "whitespace" and "white space" are used inconsistently throughout the documentation. Can we please pick one? ;) --Quanah

1 0

Re: (ITS#5757) back-null returns an error when any critical extension is specified
by ando＠sys-net.it 20 Oct '08

20 Oct '08

ando(a)sys-net.it wrote: > A different fix is in HEAD. Please test. p. A more thorough fix is now in HEAD. Please re-test. 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#5758) NO-OP control criticality
by ando＠sys-net.it 20 Oct '08

20 Oct '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> The latest draft I can find (14 February 2007) states that >> >> Clients MUST provide a >> criticality value of TRUE to prevent unintended modification of the >> directory. >> >> As a consequence, I think the server could reject instances of this control >> with a criticality of FALSE, to prevent its unintended use. > > RFC 2251 allowed that (or could be read as alllowing it), but > RFC 4511 deliberately does not, after long discussions on ldapbis. OK, backing out my latest commit. 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#5758) NO-OP control criticality
by h.b.furuseth＠usit.uio.no 20 Oct '08

20 Oct '08

ando(a)sys-net.it writes: > The latest draft I can find (14 February 2007) states that > > Clients MUST provide a > criticality value of TRUE to prevent unintended modification of the > directory. > > As a consequence, I think the server could reject instances of this control > with a criticality of FALSE, to prevent its unintended use. RFC 2251 allowed that (or could be read as alllowing it), but RFC 4511 deliberately does not, after long discussions on ldapbis. -- Hallvard

1 0

(ITS#5758) NO-OP control criticality
by ando＠sys-net.it 20 Oct '08

20 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando The latest draft I can find (14 February 2007) states that Clients MUST provide a criticality value of TRUE to prevent unintended modification of the directory. As a consequence, I think the server could reject instances of this control with a criticality of FALSE, to prevent its unintended use. However, OpenLDAP's slapd currently tolerates a criticality of FALSE, and OpenLDAP clients allow users to use this control with a criticality of FALSE. I think the clients need to be fixed, and the server should prevent this improper use. Also, the server should check whether the control is used with operations not indicated in the draft (i.e. non-write ops). p.

1 0

Re: (ITS#5625) memberOf search ACLs
by ando＠sys-net.it 20 Oct '08

20 Oct '08

abartlet(a)samba.org wrote: > Full_Name: Andrew Bartlett > Version: CVS HEAD > OS: Fedora 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (59.167.251.137) > > >>From thread on opendlap-technical: > >> Hmm, I have the module loaded globally - perhaps I need a global rootdn >> of some kind defined? >> >> I have one per-database (now), but the documentation strongly encourages >> one not to have a rootdn at all. > > The fix was to define rootdn globally (as the module operates globally), > and then to give it explicit manage access in an ACL. eg > > access to dn.subtree="${DOMAINDN}" > by dn=cn=samba-admin,cn=samba manage > by dn=cn=manager manage > by * none > > rootdn cn=Manager > > Adding a rootdn to each database then quashed the warnings about 'rootdn > can always manage'. > > Otherwise, if I had 'by * read' then this also allowed the module to operate > correctly (but without the secrecy I desired) Few considerations: 1) having a rootdn in the global database (technically, in the frontend database) is not a bad thing, since it manages no data. Moreover, having a rootdn without password means that unless anyone can authorize as it (authzTo, authz-regexp and so) there is no way anyone can take that identity. As a consequence, it's there only for the purpose of performing internal operations with a privileged identity. We have discussed many times about the possibility to define a per-operation, possibly per-database flag that states the operation is being performed as a privileged identity, but so far we sticked with the rootdn as the client's identity. What comes to my mind right now is that we could define special interfaces for internal operations, something like sockurl=privileged:// to indicate internal operations; in those cases, an otherwise anonymous operation could be identified as privileged and thus bypass access control much like it would without the need to set a rootdn. 2) you don't need to add "by dn=cn=manager manage" to global ACL rules, since that's implied. This allows you to get rid of the warning messages. You'll need to add it to rules within each database, unless cn=manager is also the rootdn of those databases. 3) adding "by dn=cn=samba-admin,cn=samba manage" to all access rules can be annoying, but that's the right way, IMHO, to deal with your specific problem; you could work it around by adding a rule like access to * by dn=cn=samba-admin,cn=samba manage by * break early enough in each database's ACLs (right after the rule that allows anonymous to bind :) This rule seems a bit to open, since it gives cn=samba-admin,cn=samba privileges comparable to those of a global rootdn. Perhaps you want to restrict them to what data is actually pertinent to Samba4? 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#5632) "overlay" directive listing in slapd.conf misleading
by ando＠sys-net.it 20 Oct '08

20 Oct '08

hyc(a)symas.com wrote: > And the frontendDB was created after > overlays were first designed; the docs just haven't caught up to this fact yet. Just to note: the frontend database (use of a backend structure to collect frontend operations, adding an extra level of indirection in operations handling) was expressly designed to allow overlays to be stacked before database selection and selected operations handling. The main driver was slapo-chain(5) used to intercept referrals returned by the frontend when one tries to write to a shadow database, and slapo-rwm(5) to intercept requests and rewrite their DN, in order to be able to interfere with database selection. 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#5757) back-null returns an error when any critical extension is specified
by ando＠sys-net.it 20 Oct '08

20 Oct '08

A different fix is in HEAD. Please test. 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#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by ando＠sys-net.it 20 Oct '08

20 Oct '08

toby(a)inf.ed.ac.uk wrote: > Full_Name: Toby Blake > Version: 2.4.11 > OS: Scientific Linux 5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (87.115.7.181) > > > Hello, > > Caching of (more complex) lookups doesn't seem to work correctly using > openldap 2.4 and slapo-pcache. > > Identical set-ups, one using openldap 2.3.43 and one using openldap > 2.4.11 (+patch for ITS #5665). Trivial testing of 2.4.12 suggests > that the problem remains. The issue is confirmed. I could reproduce it with a much simpler configuration: overlay pcache proxycache bdb 100 2 6 1m proxyattrset 0 uid proxyattrset 1 cn proxytemplate "(&(objectClass=)(uid=))" 0 1m 1m proxytemplate "(uid=)" 1 1m 1m Note that swapping the attrsets and templates does not affect it: the template with the simple filter works, while the other doesn't. I was unable to detect the root cause, but it seems to be related to query confinement, where something about the first filter does not allow to store the second query, since the first bit, (objectClass=x), is identical in both queries. Note that swapping the simple filters, making the "unique portion come first, cures the problem: overlay pcache proxycache bdb 100 2 6 1m proxyattrset 0 uid proxyattrset 1 cn proxytemplate "(&(uid=)(objectClass=))" 0 1m 1m proxytemplate "(uid=)" 1 1m 1m 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#5755) Schema file not always converted to LDIF and slapdwon't restart
by h.b.furuseth＠usit.uio.no 20 Oct '08

20 Oct '08

I wrote: > Possibly that should wait for OpenLDAP 2.5 though, and just log a > warning for now. ...though -f file -F dir should fail, of course. -- Hallvard

1 0

RE: (ITS#5755) Schema file not always converted to LDIF and slapdwon't restart
by h.b.furuseth＠usit.uio.no 20 Oct '08

20 Oct '08

The problem is the 8-bit Latin-1 character in the certificate's DESC. It works if you convert the schema file to UTF-8. Slapd should have refused to start with a non-UTF-8 attribute DESC. Possibly that should wait for OpenLDAP 2.5 though, and just log a warning for now. -- Hallvard

1 0

Re: (ITS#5757) back-null returns an error when any critical extension is specified
by ando＠sys-net.it 20 Oct '08

20 Oct '08

Kurt(a)OpenLDAP.org wrote: > On Oct 20, 2008, at 7:55 AM, jclarke(a)linagora.com wrote: > >> In case they don't support the control, success is >> returned anyway, as the man page specifies. > > That may very well violate the control's specification. > >> In case they don't support the control, success is >> returned anyway, as the man page specifies. Probably, a reasonable approach would be to actually implement support for well known controls. In most cases, its implementation would be trivial (i.e. ignore them), but it would be done in a consistent manner. For example: support for manageDSAit, pr, vlv consists in ignoring them. Support for proxied authorization is dealt with by the frontend. And so on... 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#5757) back-null returns an error when any critical extension is specified
by Kurt＠OpenLDAP.org 20 Oct '08

20 Oct '08

On Oct 20, 2008, at 7:55 AM, jclarke(a)linagora.com wrote: > In case they don't support the control, success is > returned anyway, as the man page specifies. That may very well violate the control's specification. > In case they don't support the control, success is > returned anyway, as the man page specifies. I would suggest simply updating the manual. "Searches return success" is refer to basic search operations (as requested by a search with no controls). -- Kurt

1 0

(ITS#5757) back-null returns an error when any critical extension is specified
by jclarke＠linagora.com 20 Oct '08

20 Oct '08

Full_Name: Jonathan Clarke Version: RE24 (and 2.3.x) OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.243.192) Hi folks, Considering a setup like the following: 8<------------------------------------------------ database ldap suffix "dc=remote,o=base" subordinate uri ldap://ldap.remote.com overlay rwm rwm-suffixmassage dc=remote,o=base dc=remote database null suffix "o=base" overlay glue 8<------------------------------------------------ (I realize this is of course completely useless on it's own, but associated to other backends is quite useful - this simple example is to explain this bug report only) A search of scope sub on o=base will be passed to back-ldap, performed on the remote server and the results returned. If a non-critical control is passed with a search, back-null will pass it to back-ldap, and to the remote server, with success, returning results as expected with the control. However, if a critical control is passed in the same way, back-null returns the "12 Critical extension is unavailable" error, since back-null doesn't declare support for any controls. According to the slapd-null man page for back-null: "Searches return success but no entries". The following patch changes this so that back-null declares controls in the same way back-ldap and back-meta do, and passes critical controls on to any subordinate databases. In case they don't support the control, success is returned anyway, as the man page specifies. The patch: http://milopita.phillipoux.net/jonathan-clarke-20081020.patch (this a simple copy and paste from back-ldap/back-meta)

1 0

Re: (ITS#5754) Not able to download from mirrors
by Kurt＠OpenLDAP.org 20 Oct '08

20 Oct '08

On Oct 19, 2008, at 10:46 PM, asha.murugesapandian(a)accenture.com wrote: > Full_Name: Ashalatha Murugesapandian > Version: 2.4.12 > OS: Windows XP > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (144.36.210.72) > > > Hi, > > I am not able to download openldap from any mirror. It is showing > "Page can not > be displayed" message. Can you please let me know the solution to > download > OPENLDAP software? > > Regards, > Ashalatha Murugesapandian > > As downloading of files from our primary site and mirrors appears to be working just fine for others (including me), this appears to be a problem at your system/network. I suggest you contact your IT department for assistance/advice. -- Kurt

1 0

(ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by toby＠inf.ed.ac.uk 20 Oct '08

20 Oct '08

Full_Name: Toby Blake Version: 2.4.11 OS: Scientific Linux 5.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.115.7.181) Hello, Caching of (more complex) lookups doesn't seem to work correctly using openldap 2.4 and slapo-pcache. Identical set-ups, one using openldap 2.3.43 and one using openldap 2.4.11 (+patch for ITS #5665). Trivial testing of 2.4.12 suggests that the problem remains. Here's the pcache part of slapd.conf: overlay pcache proxycache bdb 5000 2 500 300 proxycachequeries 10000 proxyattrset 0 primaryRoles secondaryRoles cn proxyattrset 1 uid userPassword uidNumber gidNumber cn afsHomeDirecto ry loginShell gecos description objectClass proxytemplate (uid=) 0 600 600 proxytemplate (&(objectClass=)(uid=)) 1 600 600 All works as expected with 2.3.43. With 2.4: The "(uid=)" template works fine all lookups. What happens, for the "(&(objectClass=)(uid=))" template, is that only the first lookup will be correctly cached, whether the results are positive or negative. Subsequent different lookups which match that template will log 'QUERY NOT ANSWERABLE; QUERY CACHEABLE' but the entry won't be successfully cached (in that the next identical lookup will also log 'QUERY NOT ANSWERABLE; QUERY CACHEABLE' and fetch the entry from the remote server). I've attached a portion of the slapd log below this message which shows the results of the following: <slapd starting>... ldapsearch -x -h localhost "(&(objectClass=posixAccount)(uid=toby))" uid ldapsearch -x -h localhost "(&(objectClass=posixAccount)(uid=toby))" uid ldapsearch -x -h localhost "(&(objectClass=posixAccount)(uid=bill))" uid ldapsearch -x -h localhost "(&(objectClass=posixAccount)(uid=bill))" uid ...<cache expiry>... ldapsearch -x -h localhost "(&(objectClass=posixAccount)(uid=bill))" uid ldapsearch -x -h localhost "(&(objectClass=posixAccount)(uid=bill))" uid ldapsearch -x -h localhost "(&(objectClass=posixAccount)(uid=toby))" uid ldapsearch -x -h localhost "(&(objectClass=posixAccount)(uid=toby))" uid In the first case the lookup for "...uid=toby" is successfully cached, while the one for "...uid=bill" isn't. After cache expiry, the reverse is true. If there is any more information that would be useful, or debugging I could do, please let me know. Many thanks Toby Blake School of Informatics University of Edinburgh Oct 20 14:20:16 sybies slapd[8187]: @(#) $OpenLDAP: slapd 2.4.11 (Aug 25 2008 11:25:11) $ toby@syd.inf.ed.ac.uk:/afs/inf.ed.ac.uk/user/t/toby/linux/BUILD/openldap-2.4.11/openldap-2.4.11/servers/slapd Oct 20 14:20:16 sybies slapd[8187]: Total # of attribute sets to be cached = 2. Oct 20 14:20:16 sybies slapd[8187]: Template: Oct 20 14:20:16 sybies slapd[8187]: query template: (uid=) Oct 20 14:20:16 sybies slapd[8187]: attributes: Oct 20 14:20:16 sybies slapd[8187]: primaryRoles Oct 20 14:20:16 sybies slapd[8187]: secondaryRoles Oct 20 14:20:16 sybies slapd[8187]: cn Oct 20 14:20:16 sybies slapd[8187]: Template: Oct 20 14:20:16 sybies slapd[8187]: query template: (&(objectClass=)(uid=)) Oct 20 14:20:16 sybies slapd[8187]: attributes: Oct 20 14:20:16 sybies slapd[8187]: uid Oct 20 14:20:16 sybies slapd[8187]: userPassword Oct 20 14:20:16 sybies slapd[8187]: uidNumber Oct 20 14:20:16 sybies slapd[8187]: gidNumber Oct 20 14:20:16 sybies slapd[8187]: cn Oct 20 14:20:16 sybies slapd[8187]: afsHomeDirectory Oct 20 14:20:16 sybies slapd[8187]: loginShell Oct 20 14:20:16 sybies slapd[8187]: gecos Oct 20 14:20:16 sybies slapd[8187]: description Oct 20 14:20:16 sybies slapd[8187]: objectClass Oct 20 14:20:16 sybies slapd[8189]: slapd starting Oct 20 14:20:30 sybies slapd[8189]: conn=0 fd=16 ACCEPT from IP=127.0.0.1:60516 (IP=0.0.0.0:389) Oct 20 14:20:30 sybies slapd[8189]: conn=0 op=0 BIND dn="" method=128 Oct 20 14:20:30 sybies slapd[8189]: conn=0 op=1 SRCH base="dc=inf,dc=ed,dc=ac,dc=uk" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=toby))" Oct 20 14:20:30 sybies slapd[8189]: conn=0 op=1 SRCH attr=uid Oct 20 14:20:30 sybies slapd[8189]: query template of incoming query = (&(objectClass=)(uid=)) Oct 20 14:20:30 sybies slapd[8189]: Entering QC, querystr = (&(objectClass=posixAccount)(uid=toby)) Oct 20 14:20:30 sybies slapd[8189]: Lock QC index = 0x8cc25c8 Oct 20 14:20:30 sybies slapd[8189]: Not answerable: Unlock QC index=0x8cc25c8 Oct 20 14:20:30 sybies slapd[8189]: QUERY NOT ANSWERABLE Oct 20 14:20:30 sybies slapd[8189]: QUERY CACHEABLE Oct 20 14:20:30 sybies slapd[8189]: conn=0 op=0 RESULT tag=97 err=0 text= Oct 20 14:20:30 sybies slapd[8189]: Added query expires at 1224509430 (POSITIVE) Oct 20 14:20:30 sybies slapd[8189]: Lock AQ index = 0x8cc25c8 Oct 20 14:20:30 sybies slapd[8189]: TEMPLATE 0x8cc25c8 QUERIES++ 1 Oct 20 14:20:30 sybies slapd[8189]: Unlock AQ index = 0x8cc25c8 Oct 20 14:20:30 sybies slapd[8189]: Base of added query = dc=inf,dc=ed,dc=ac,dc=uk Oct 20 14:20:30 sybies slapd[8189]: UUID for query being added = 9cfdd1c0-32f5-102d-88aa-9ff265a4b255 Oct 20 14:20:30 sybies slapd[8189]: conn=0 op=2 UNBIND Oct 20 14:20:31 sybies slapd[8189]: ENTRY ADDED/MERGED, CACHED ENTRIES=1 Oct 20 14:20:31 sybies slapd[8189]: STORED QUERIES = 1 Oct 20 14:20:31 sybies slapd[8189]: conn=0 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 20 14:20:31 sybies slapd[8189]: conn=0 fd=16 closed Oct 20 14:20:33 sybies slapd[8189]: conn=1 fd=16 ACCEPT from IP=127.0.0.1:60518 (IP=0.0.0.0:389) Oct 20 14:20:33 sybies slapd[8189]: conn=1 op=0 BIND dn="" method=128 Oct 20 14:20:33 sybies slapd[8189]: conn=1 op=0 RESULT tag=97 err=0 text= Oct 20 14:20:33 sybies slapd[8189]: conn=1 op=1 SRCH base="dc=inf,dc=ed,dc=ac,dc=uk" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=toby))" Oct 20 14:20:33 sybies slapd[8189]: conn=1 op=1 SRCH attr=uid Oct 20 14:20:33 sybies slapd[8189]: query template of incoming query = (&(objectClass=)(uid=)) Oct 20 14:20:33 sybies slapd[8189]: Entering QC, querystr = (&(objectClass=posixAccount)(uid=toby)) Oct 20 14:20:33 sybies slapd[8189]: Lock QC index = 0x8cc25c8 Oct 20 14:20:33 sybies slapd[8189]: QUERY ANSWERABLE Oct 20 14:20:33 sybies slapd[8189]: conn=1 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 20 14:20:33 sybies slapd[8189]: conn=1 op=2 UNBIND Oct 20 14:20:33 sybies slapd[8189]: conn=1 fd=16 closed Oct 20 14:20:40 sybies slapd[8189]: conn=2 fd=16 ACCEPT from IP=127.0.0.1:60519 (IP=0.0.0.0:389) Oct 20 14:20:40 sybies slapd[8189]: conn=2 op=0 BIND dn="" method=128 Oct 20 14:20:40 sybies slapd[8189]: conn=2 op=0 RESULT tag=97 err=0 text= Oct 20 14:20:40 sybies slapd[8189]: conn=2 op=1 SRCH base="dc=inf,dc=ed,dc=ac,dc=uk" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=bill))" Oct 20 14:20:40 sybies slapd[8189]: conn=2 op=1 SRCH attr=uid Oct 20 14:20:40 sybies slapd[8189]: query template of incoming query = (&(objectClass=)(uid=)) Oct 20 14:20:40 sybies slapd[8189]: Entering QC, querystr = (&(objectClass=posixAccount)(uid=bill)) Oct 20 14:20:40 sybies slapd[8189]: Lock QC index = 0x8cc25c8 Oct 20 14:20:40 sybies slapd[8189]: Not answerable: Unlock QC index=0x8cc25c8 Oct 20 14:20:40 sybies slapd[8189]: QUERY NOT ANSWERABLE Oct 20 14:20:40 sybies slapd[8189]: QUERY CACHEABLE Oct 20 14:20:40 sybies slapd[8189]: Added query expires at 1224509440 (POSITIVE) Oct 20 14:20:40 sybies slapd[8189]: Lock AQ index = 0x8cc25c8 Oct 20 14:20:40 sybies slapd[8189]: TEMPLATE 0x8cc25c8 QUERIES++ 1 Oct 20 14:20:40 sybies slapd[8189]: Unlock AQ index = 0x8cc25c8 Oct 20 14:20:40 sybies slapd[8189]: conn=2 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 20 14:20:40 sybies slapd[8189]: conn=2 op=2 UNBIND Oct 20 14:20:40 sybies slapd[8189]: conn=2 fd=16 closed Oct 20 14:20:42 sybies slapd[8189]: conn=3 fd=16 ACCEPT from IP=127.0.0.1:60520 (IP=0.0.0.0:389) Oct 20 14:20:42 sybies slapd[8189]: conn=3 op=0 BIND dn="" method=128 Oct 20 14:20:42 sybies slapd[8189]: conn=3 op=0 RESULT tag=97 err=0 text= Oct 20 14:20:42 sybies slapd[8189]: conn=3 op=1 SRCH base="dc=inf,dc=ed,dc=ac,dc=uk" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=bill))" Oct 20 14:20:42 sybies slapd[8189]: conn=3 op=1 SRCH attr=uid Oct 20 14:20:42 sybies slapd[8189]: query template of incoming query = (&(objectClass=)(uid=)) Oct 20 14:20:42 sybies slapd[8189]: Entering QC, querystr = (&(objectClass=posixAccount)(uid=bill)) Oct 20 14:20:42 sybies slapd[8189]: Lock QC index = 0x8cc25c8 Oct 20 14:20:42 sybies slapd[8189]: Not answerable: Unlock QC index=0x8cc25c8 Oct 20 14:20:42 sybies slapd[8189]: QUERY NOT ANSWERABLE Oct 20 14:20:42 sybies slapd[8189]: QUERY CACHEABLE Oct 20 14:20:42 sybies slapd[8189]: Added query expires at 1224509442 (POSITIVE) Oct 20 14:20:42 sybies slapd[8189]: Lock AQ index = 0x8cc25c8 Oct 20 14:20:42 sybies slapd[8189]: TEMPLATE 0x8cc25c8 QUERIES++ 1 Oct 20 14:20:42 sybies slapd[8189]: Unlock AQ index = 0x8cc25c8 Oct 20 14:20:42 sybies slapd[8189]: conn=3 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 20 14:20:42 sybies slapd[8189]: conn=3 op=2 UNBIND Oct 20 14:20:42 sybies slapd[8189]: conn=3 fd=16 closed Oct 20 14:30:31 sybies slapd[8189]: Lock CR index = 0x8cc25c8 Oct 20 14:30:31 sybies slapd[8189]: TEMPLATE 0x8cc25c8 QUERIES-- 0 Oct 20 14:30:31 sybies slapd[8189]: Unlock CR index = 0x8cc25c8 Oct 20 14:30:31 sybies slapd[8189]: DELETING ENTRY TEMPLATE=9cfdd1c0-32f5-102d-88aa-9ff265a4b255 Oct 20 14:30:31 sybies slapd[8189]: STALE QUERY REMOVED, SIZE=1 Oct 20 14:30:31 sybies slapd[8189]: STORED QUERIES = 0 Oct 20 14:30:31 sybies slapd[8189]: STALE QUERY REMOVED, CACHE =0 entries Oct 20 14:31:50 sybies slapd[8189]: conn=4 fd=16 ACCEPT from IP=127.0.0.1:52101 (IP=0.0.0.0:389) Oct 20 14:31:50 sybies slapd[8189]: conn=4 op=0 BIND dn="" method=128 Oct 20 14:31:50 sybies slapd[8189]: conn=4 op=0 RESULT tag=97 err=0 text= Oct 20 14:31:50 sybies slapd[8189]: conn=4 op=1 SRCH base="dc=inf,dc=ed,dc=ac,dc=uk" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=bill))" Oct 20 14:31:50 sybies slapd[8189]: conn=4 op=1 SRCH attr=uid Oct 20 14:31:50 sybies slapd[8189]: query template of incoming query = (&(objectClass=)(uid=)) Oct 20 14:31:50 sybies slapd[8189]: Entering QC, querystr = (&(objectClass=posixAccount)(uid=bill)) Oct 20 14:31:50 sybies slapd[8189]: Lock QC index = 0x8cc25c8 Oct 20 14:31:50 sybies slapd[8189]: Not answerable: Unlock QC index=0x8cc25c8 Oct 20 14:31:50 sybies slapd[8189]: QUERY NOT ANSWERABLE Oct 20 14:31:50 sybies slapd[8189]: QUERY CACHEABLE Oct 20 14:31:50 sybies slapd[8189]: Added query expires at 1224510110 (POSITIVE) Oct 20 14:31:50 sybies slapd[8189]: Lock AQ index = 0x8cc25c8 Oct 20 14:31:50 sybies slapd[8189]: TEMPLATE 0x8cc25c8 QUERIES++ 1 Oct 20 14:31:50 sybies slapd[8189]: Unlock AQ index = 0x8cc25c8 Oct 20 14:31:50 sybies slapd[8189]: Base of added query = dc=inf,dc=ed,dc=ac,dc=uk Oct 20 14:31:50 sybies slapd[8189]: UUID for query being added = 321f6e16-32f7-102d-88ab-9ff265a4b255 Oct 20 14:31:50 sybies slapd[8189]: conn=4 op=2 UNBIND Oct 20 14:31:50 sybies slapd[8189]: ENTRY ADDED/MERGED, CACHED ENTRIES=1 Oct 20 14:31:50 sybies slapd[8189]: STORED QUERIES = 1 Oct 20 14:31:50 sybies slapd[8189]: conn=4 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 20 14:31:50 sybies slapd[8189]: conn=4 fd=16 closed Oct 20 14:31:53 sybies slapd[8189]: conn=5 fd=16 ACCEPT from IP=127.0.0.1:52103 (IP=0.0.0.0:389) Oct 20 14:31:53 sybies slapd[8189]: conn=5 op=0 BIND dn="" method=128 Oct 20 14:31:53 sybies slapd[8189]: conn=5 op=0 RESULT tag=97 err=0 text= Oct 20 14:31:53 sybies slapd[8189]: conn=5 op=1 SRCH base="dc=inf,dc=ed,dc=ac,dc=uk" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=bill))" Oct 20 14:31:53 sybies slapd[8189]: conn=5 op=1 SRCH attr=uid Oct 20 14:31:53 sybies slapd[8189]: query template of incoming query = (&(objectClass=)(uid=)) Oct 20 14:31:53 sybies slapd[8189]: Entering QC, querystr = (&(objectClass=posixAccount)(uid=bill)) Oct 20 14:31:53 sybies slapd[8189]: Lock QC index = 0x8cc25c8 Oct 20 14:31:53 sybies slapd[8189]: QUERY ANSWERABLE Oct 20 14:31:53 sybies slapd[8189]: conn=5 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 20 14:31:53 sybies slapd[8189]: conn=5 op=2 UNBIND Oct 20 14:31:53 sybies slapd[8189]: conn=5 fd=16 closed Oct 20 14:32:00 sybies slapd[8189]: conn=6 fd=16 ACCEPT from IP=127.0.0.1:52104 (IP=0.0.0.0:389) Oct 20 14:32:00 sybies slapd[8189]: conn=6 op=0 BIND dn="" method=128 Oct 20 14:32:00 sybies slapd[8189]: conn=6 op=0 RESULT tag=97 err=0 text= Oct 20 14:32:00 sybies slapd[8189]: conn=6 op=1 SRCH base="dc=inf,dc=ed,dc=ac,dc=uk" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=toby))" Oct 20 14:32:00 sybies slapd[8189]: conn=6 op=1 SRCH attr=uid Oct 20 14:32:00 sybies slapd[8189]: query template of incoming query = (&(objectClass=)(uid=)) Oct 20 14:32:00 sybies slapd[8189]: Entering QC, querystr = (&(objectClass=posixAccount)(uid=toby)) Oct 20 14:32:00 sybies slapd[8189]: Lock QC index = 0x8cc25c8 Oct 20 14:32:00 sybies slapd[8189]: Not answerable: Unlock QC index=0x8cc25c8 Oct 20 14:32:00 sybies slapd[8189]: QUERY NOT ANSWERABLE Oct 20 14:32:00 sybies slapd[8189]: QUERY CACHEABLE Oct 20 14:32:00 sybies slapd[8189]: Added query expires at 1224510120 (POSITIVE) Oct 20 14:32:00 sybies slapd[8189]: Lock AQ index = 0x8cc25c8 Oct 20 14:32:00 sybies slapd[8189]: TEMPLATE 0x8cc25c8 QUERIES++ 1 Oct 20 14:32:00 sybies slapd[8189]: Unlock AQ index = 0x8cc25c8 Oct 20 14:32:00 sybies slapd[8189]: conn=6 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 20 14:32:00 sybies slapd[8189]: conn=6 op=2 UNBIND Oct 20 14:32:00 sybies slapd[8189]: conn=6 fd=16 closed Oct 20 14:32:05 sybies slapd[8189]: conn=7 fd=16 ACCEPT from IP=127.0.0.1:52105 (IP=0.0.0.0:389) Oct 20 14:32:05 sybies slapd[8189]: conn=7 op=0 BIND dn="" method=128 Oct 20 14:32:05 sybies slapd[8189]: conn=7 op=0 RESULT tag=97 err=0 text= Oct 20 14:32:05 sybies slapd[8189]: conn=7 op=1 SRCH base="dc=inf,dc=ed,dc=ac,dc=uk" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=toby))" Oct 20 14:32:05 sybies slapd[8189]: conn=7 op=1 SRCH attr=uid Oct 20 14:32:05 sybies slapd[8189]: query template of incoming query = (&(objectClass=)(uid=)) Oct 20 14:32:05 sybies slapd[8189]: Entering QC, querystr = (&(objectClass=posixAccount)(uid=toby)) Oct 20 14:32:05 sybies slapd[8189]: Lock QC index = 0x8cc25c8 Oct 20 14:32:05 sybies slapd[8189]: Not answerable: Unlock QC index=0x8cc25c8 Oct 20 14:32:05 sybies slapd[8189]: QUERY NOT ANSWERABLE Oct 20 14:32:05 sybies slapd[8189]: QUERY CACHEABLE Oct 20 14:32:05 sybies slapd[8189]: Added query expires at 1224510125 (POSITIVE) Oct 20 14:32:05 sybies slapd[8189]: Lock AQ index = 0x8cc25c8 Oct 20 14:32:05 sybies slapd[8189]: TEMPLATE 0x8cc25c8 QUERIES++ 1 Oct 20 14:32:05 sybies slapd[8189]: Unlock AQ index = 0x8cc25c8 Oct 20 14:32:05 sybies slapd[8189]: conn=7 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 20 14:32:05 sybies slapd[8189]: conn=7 op=2 UNBIND Oct 20 14:32:05 sybies slapd[8189]: conn=7 fd=16 closed

1 0

RE: (ITS#5755) Schema file not always converted to LDIF and slapd won'trestart
by emmanuel.duru＠atosorigin.com 20 Oct '08

20 Oct '08

The missing attributes appear in attributeTypes in cn=subschema. I can't perform a search on cn=config because I have not set rootdn for cn=config yet (I have to do it in the ldif file and restart slapd, but it doesn't restart...) > -----Message d'origine----- > De : Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no] > Envoyé : lundi 20 octobre 2008 14:30 > À : emmanuel.duru(a)atosorigin.com > Cc : openldap-its(a)openldap.org > Objet : Re: (ITS#5755) Schema file not always converted to LDIF and slapd > won'trestart > > Can you post a slapd.conf and the necessary file files which cause > this? Or an URL to them? Remember to remove passwords. > > Since you say slapd won't restart, I assume it does start the first > time. When slapd starts up and writes such a bad schema directory, > do the missing attributes show up with ldapsearch... > ...in olcAttributeTypes in cn={n}filename,cn=schema,cn=config? > ...in attributeTypes in cn=subschema with search scope = base? > > -- > Hallvard

1 0

RE: (ITS#5755) Schema file not always converted to LDIF and slapdwon't restart
by emmanuel.duru＠atosorigin.com 20 Oct '08

20 Oct '08

This is a multi-part message in MIME format. ------=_NextPart_000_004C_01C932C2.F4BA15D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here is a test slapd conf file, with a test schema. Put the test.schema in schema subdirectory, together with standard = schema files. Run slapd -f slapdTest.conf -F /path/configdb Slapd starts and can be accessed this time, all is fine. But when restarting with the configdb only, it does not start: olcObjectClasses: value #0 olcObjectClasses: AttributeType not found: "mailHost" config error processing cn=3D{3}test,cn=3Dschema,cn=3Dconfig: = olcObjectClasses: AttributeType not found: "mailHost" and the /path/configdb/cn=3Dconfig/cn=3Dschema/cn=3D{3}test.ldif = contains this: dn: cn=3D{3}test objectClass: olcSchemaConfig cn: {3}test olcObjectClasses: {0}( 1.2.250.1.49.4406.0.6.1 NAME 'museIncr2' SUP top AUXILI ARY MAY ( uid $ manager $ employeeNumber $ departmentNumber $ mailHost = $ intr acedUid $ source $ userCertificateIGCG $ modifiedTimestampSource ) ) structuralObjectClass: olcSchemaConfig entryUUID: c28d5168-40ed-4af9-8583-a02786da8bc8 creatorsName: cn=3Dconfig createTimestamp: 20081020124051Z entryCSN: 20081020124051.109000Z#000000#000#000000 modifiersName: cn=3Dconfig modifyTimestamp: 20081020124051Z > -----Message d'origine----- > De=A0: Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no] > Envoy=E9=A0: lundi 20 octobre 2008 14:32 > =C0=A0: emmanuel.duru(a)atosorigin.com > Objet=A0: Re: (ITS#5755) Schema file not always converted to LDIF and > slapdwon't restart Can you post a slapd.conf and the necessary file files which cause this? Or an URL to them? Remember to remove passwords. Since you say slapd won't restart, I assume it does start the first time. When slapd starts up and writes such a bad schema directory, do the missing attributes show up with ldapsearch... ...in olcAttributeTypes in cn=3D{n}filename,cn=3Dschema,cn=3Dconfig? ...in attributeTypes in cn=3Dsubschema with search scope =3D base?>=20 > h.b.furuseth(a)usit.uio.no writes: > > Can you post a slapd.conf and the necessary file files >=20 > Eh. I mean the necessary schema files, of course. >=20 > -- > Hallvard ------=_NextPart_000_004C_01C932C2.F4BA15D0 Content-Type: application/octet-stream; name="slapdTest.conf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="slapdTest.conf" # $OpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v 1.23.2.2 2002/08/19 = 16:21:49 kurt Exp $ # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # ucdata-path ucdata #loglevel 4072 loglevel 4095 logfile slapd-m.log include schema/core.schema include schema/cosine.schema include schema/inetorgperson.schema include schema/test.schema pidfile slapd.pid argsfile slapd.args allow bind_v2 access to * attr=3DuserPassword=0A= by self write=0A= by anonymous auth=0A= by * none access to * by self write=0A= by users read by anonymous read by * none ####################################################################### # database definitions ####################################################################### database bdb suffix "c=3Dfr" rootdn "cn=3Dmanager,c=3Dfr" # number of entries which should be held in memory cachesize 20000 # Specify how often the berkeley database transaction log is = checkpointed.=20 # A checkpoint will occur when either <kbytes> of data have been written = to=20 # the transaction logs, or <min> minutes have passed since the last = checkpoint,=20 # which ever comes first. # -> done by syncprov # checkpoint 10000 10 updatedn "cn=3Dmanager,c=3Dfr" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA}IcRbIFvDVZ9j6g8hWK9bbgo7xhSrMMTf # The database directory MUST exist prior to running slapd AND=20 # should only be accessible by the slapd/tools. Mode 700 recommended. directory db # Indices to maintain index objectClass,entryCSN,entryUUID eq index cn,ou,sn,telephonenumber eq,sub # for replication overlay syncprov # <nb ops> <minutes> syncprov-checkpoint 100 10 # nb of session log entries syncprov-sessionlog 100 ------=_NextPart_000_004C_01C932C2.F4BA15D0 Content-Type: application/octet-stream; name="test.schema" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="test.schema" attributetype ( 1.3.6.1.4.1.7914.1.2.1.6 NAME 'mailHost' DESC 'Nom du serveur destinataire' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 SINGLE-VALUE ) attributetype ( 1.2.250.1.49.5.17 NAME 'intracedUid' DESC 'Identifiant Intranet' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) attributetype ( 1.2.250.1.49.5.16 NAME 'source' DESC 'Annuaire Source' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) attributetype ( 1.2.250.1.49.4406.0.0.5 NAME 'userCertificateIGCG' DESC 'Certificats de l=92IGC generique' EQUALITY certificateExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) attributetype ( 1.2.250.1.49.4406.0.0.6 NAME 'modifiedTimestampSource' DESC 'Date de modification d une entree issue de l annuaire = externe' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24=20 SINGLE-VALUE ) objectclass ( 1.2.250.1.49.4406.0.6.1 NAME 'museIncr2' SUP top AUXILIARY MAY ( uid $ manager $ employeeNumber $ departmentNumber $ mailHost $ intracedUid $ source $ userCertificateIGCG $ = modifiedTimestampSource ) ) ------=_NextPart_000_004C_01C932C2.F4BA15D0--

1 0

Re: (ITS#5755) Schema file not always converted to LDIF and slapd won't restart
by h.b.furuseth＠usit.uio.no 20 Oct '08

20 Oct '08

Can you post a slapd.conf and the necessary file files which cause this? Or an URL to them? Remember to remove passwords. Since you say slapd won't restart, I assume it does start the first time. When slapd starts up and writes such a bad schema directory, do the missing attributes show up with ldapsearch... ...in olcAttributeTypes in cn={n}filename,cn=schema,cn=config? ...in attributeTypes in cn=subschema with search scope = base? -- Hallvard

1 0

(ITS#5755) Schema file not always converted to LDIF and slapd won't restart
by emmanuel.duru＠atosorigin.com 20 Oct '08

20 Oct '08

Full_Name: Emmanuel Duru Version: 2.4.11 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.78.0.137) I am starting OpenLDAP with -f slapd.conf -F /path/configdir to convert my configuration to LDIF, including customized schema. My customized schema is split in several files. Sometimes, the attributes defined in one of these files are not generated in the configdb LDIF files (the cn={n}xx.ldif file in the /path/configdb/cn=config/cn=schema directory does not contain any olcAttributeTypes values, though it contains the corresponding olcObjectClasses attributes). After several tests, the problem seems to come from an attribute with Certificate syntax: as soon as one xx.schema file contains such an attribute, the corresponding {n}xx.ldif file does not contain any olcAttributeTypes attribute). This works with core.schema (usercertificate for example), but I can't see any difference with my certificate attribute.

1 0

(ITS#5754) Not able to download from mirrors
by asha.murugesapandian＠accenture.com 19 Oct '08

19 Oct '08

Full_Name: Ashalatha Murugesapandian Version: 2.4.12 OS: Windows XP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (144.36.210.72) Hi, I am not able to download openldap from any mirror. It is showing "Page can not be displayed" message. Can you please let me know the solution to download OPENLDAP software? Regards, Ashalatha Murugesapandian

1 0

Re: (ITS#5734) Serch limits by baseDN
by ando＠sys-net.it 19 Oct '08

19 Oct '08

h.b.furuseth(a)usit.uio.no wrote: > I wrote: >> Here a suggested patch, currently a quick hack for inspection. > > I forgot slap.h. Added it now. And manpage while I'm at it. > >> This needs an API change: Currently slapd/limits.c:limits_gets() >> takes the bound DN as an argument. The change needs a function >> which fetches the bound or examined DN from the Operation structure. > > Typo, it's slapd/limits.c:limits_get() > >> Is it OK to just remove the DN argument and make the function >> static, so any existing binaries that call it won't silently get >> the changed API? Slapd doesn't call this function anywhere. > > ..it's not called anywhere _else_, that is. Sounds good for me. 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#5751) undefined value in slapo-constraint with bad filter
by ando＠sys-net.it 19 Oct '08

19 Oct '08

michael(a)stroeder.com wrote: > hyc(a)symas.com wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> Full_Name: Hallvard B Furuseth >>> Version: HEAD, RE24 >>> OS: >>> URL: >>> Submission from: (NULL) (129.240.6.233) >>> Submitted by: hallvard >>> >>> >>> overlays/constraint.c:constraint_violation() uses and maybe returns an >>> undefined value in 'rc' if the filter is bad (nop.ors_filter == NULL). >>> >>> I have no idea what rc should be in this case. >>> >>> Introduced in constraint.c 1.18 (OpenLDAP 2.4.12). >> Probably should just set rc=LDAP_SUCCESS in this case. The constraint is >> invalid, so it cannot be violated. > > Hmm, I'd prefer a strong indication that the constraint is invalid. > > If it can be proven that the filter is bad slapo-constraint should > probably stop during startup with an appropriate message. Otherwise > returning constraintViolation would be appropriate either since the LDAP > client fails then and it makes admins search for the cause of it. I concur. I've made slapo-constraint(5) return LDAP_OTHER, so it's clear that there's something wrong. Returning LDAP_CONSTRAINT_VIOLATION would have erroneously indicated that the value was not allowed but everything was working fine. Please test. 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs