openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#6247)
by Kurt＠OpenLDAP.org 02 May '10

02 May '10

In regards to my X.501 comments, see "Matching Rule Requirements" = section of X.501(93). Note that only the 93 edition is normative here. I note that you actually need to specify the syntaxes and matching rules = in X.500 terms, and then simply specify a string representation for the = syntaxes for use in LDAP. See RFC 4521, Section 5.1 (for LDAP Syntaxes) = and 5.2 (for Matching Rules) and Section 5 more generally for schema. As far as your I-D goes, I currently deferring to Steve's initial review = at this early stage in its development because I'm busy and I trust = Steve to tease out any obvious ASN.1, X.500, and/or LDAP issues with = your I-D and to "educate" you as might be necessary. I'll join in = later, possibly after you revise your I-D once or twice to address = Steve's comments. -- Kurt=

1 0

Re: (ITS#6247)
by daniel＠pluta.biz 02 May '10

02 May '10

Kurt Zeilenga schrieb: > On May 1, 2010, at 12:31 PM, daniel(a)pluta.biz wrote: > >> The patch can be downloaded here: >> ftp://ftp.openldap.org/incoming/daniel-pluta-100501.patch >> >> Changes: >> - removed extensible matching rules strictly associated with >> dedicated syntaxes >> - added two universal matching rules instead: >> - nowMach (equality matching rule) >> - nowOrdering (ordering matching rule) >> - these two rules also support extensible match filters > > Your comments imply these rules could be used as attribute type > equality and ordering rules. In general my intention is neither to violate X.501 nor changing the ASN.1 Generalized Time syntax. Instead the introduction of a compatible/similar/derived attribute value syntax (e.g. generalizedTime') which supports matching against client-side known time-stamps *and* server-relative time-stamps (like NOW or NOW-1Y3M... or X.680 period formats) seems to be fine for me. In the following generalizedTime' is such a kind of a (very) similar syntax to the well-defined generalizedTime. Regarding the EQ/ORD matching rule applicability: The attribute type is generalizedTime' and the assertion value is for example NOW which server-internally implicitly also represents a (at least some kind of possibly not ITU specified?) generalizedTime' conform assertion value: NOW is the at client side unknown current time of the server in generalizedTime'. What's your suggestion regarding a possible solution on how to support EQ and ORD matching of attribute values compared to the server side current time? > I don't believe the met the > requirements (see X.501) to be used in that manner. That is, they > only make sense as extensible matching rules. I really would like to try to understand your concerns. Could you please give me some links to chapters/sections in X.501 where I can find more details. Note: I've currently only access to the standard of the year 2006. The class is generalizedTime' and during EQ/ORD matching two instances of generalizedTime' are compared: 1. Attribute value of an entry (generalizedTime') 2. Assertion value aka expanded-NOW (generalizedTime') >> To publish a correct server current time time-stamp value within Root-DSE: >> - apply the bugfix from ITS#6541 >> - and use -DCTM_G_DIFFERENTIAL_SERVERTIME > > #ifdef's should, IMO, be generally avoided. it will be removed as soon as the above mentioned bug is fixed in HEAD >> To extend generalizedTime attribute types to also support "NOW" as >> assertion value: >> - use -DCTM_RFC4517_MR_AV_SYNTAX_VIOLATION > > The generalized time syntax is not ours to alter. Introduction of > such a change would, it seem, lead to interoperability problems. In my opinion the chosen name for the #ifdef is more than obvious. Additionally the related comment in the patch's source already say's that this "extension" is more a violation than an extension. That's why the #ifdef currently is and probably stays in action (or will be removed) in the future. As a side-effect this #ifdef could possibly invoke some disussions... ;-) It's probably worth to discuss this (violation) in more detail to provide a solution in regard to a broader applicability of this matching feature in LDAP. Broader/easier usage/readbility is also the background I've decided to skip the extensible matching rules and introduce EQ and ORD instead. E.g. Clients that are connecting to a server that announces the supportedFeature "current time matching" could make notice of that and also support "NOW" as assertion value for createTimestamp and so on... (I've not very well thought about that in detail, yet). You are right, it's just a work in progress and you are very welcome to join the discussion on ldapext.

1 0

Re: (ITS#6542) Segmentation Fault if config file (ldif) got changed
by hyc＠symas.com 01 May '10

01 May '10

felix.schuster(a)gmx.at wrote: > Full_Name: Felix > Version: 2.4.19 > OS: Linux/Gentoo > URL: > Submission from: (NULL) (78.142.131.97) > > > Using the new configuration scheme, I changed > /etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif of a running openldap > instance. When I tried to restart openldap it gaves me a Segmentation Fault > error. Even if I called the changes off, openldap refused to start (furthermore > segfaulted). I needed to get a copy of the original configuration file from my > backup to successfully start openldap again. > I think it's somewhere ok to deny working with a hand-changed configuration, but > I think we will need a friendly advise, no unfriendly Segementation Fault error. > cn=config is an LDAP database. Like any other LDAP database, you are only supposed to use ldapadd/modify/delete to write to it while slapd is running. You would probably get segfaults if you hand-edited the data files in a back-bdb database too. And no, we will not add code to protect from such misuse. -- -- 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#6542) Segmentation Fault if config file (ldif) got changed
by felix.schuster＠gmx.at 01 May '10

01 May '10

Full_Name: Felix Version: 2.4.19 OS: Linux/Gentoo URL: Submission from: (NULL) (78.142.131.97) Using the new configuration scheme, I changed /etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif of a running openldap instance. When I tried to restart openldap it gaves me a Segmentation Fault error. Even if I called the changes off, openldap refused to start (furthermore segfaulted). I needed to get a copy of the original configuration file from my backup to successfully start openldap again. I think it's somewhere ok to deny working with a hand-changed configuration, but I think we will need a friendly advise, no unfriendly Segementation Fault error.

1 0

Re: (ITS#6247)
by Kurt＠OpenLDAP.org 01 May '10

01 May '10

On May 1, 2010, at 12:31 PM, daniel(a)pluta.biz wrote: > Hi, >=20 > just some changes and cleanups according the still ongoing discussion = on=20 > ldapext. I recommend consideration of this patch be deferred until the = specification is less of a work-in-a-progress. >=20 > The patch can be downloaded here:=20 > ftp://ftp.openldap.org/incoming/daniel-pluta-100501.patch >=20 > Changes: > - removed extensible matching rules strictly associated with=20 > dedicated syntaxes > - added two universal matching rules instead: > - nowMach (equality matching rule) > - nowOrdering (ordering matching rule) > - these two rules also support extensible match filters Your comments imply these rules could be used as attribute type equality = and ordering rules. I don't believe the met the requirements (see = X.501) to be used in that manner. That is, they only make sense as = extensible matching rules. >=20 > To publish a correct server current time time-stamp value within = Root-DSE: > - apply the bugfix from ITS#6541 > - and use -DCTM_G_DIFFERENTIAL_SERVERTIME #ifdef's should, IMO, be generally avoided. >=20 >=20 > To extend generalizedTime attribute types to also support "NOW" as=20 > assertion value: > - use -DCTM_RFC4517_MR_AV_SYNTAX_VIOLATION The generalized time syntax is not ours to alter. Introduction of such = a change would, it seem, lead to interoperability problems. >=20 >=20 > Beware of patching conflicts in schema_init.c: > This patch contains small redundant parts from my parallel = contribution=20 > in ITS#6532 >=20 > Regards, > Daniel >=20 >=20

1 0

(ITS#6247)
by daniel＠pluta.biz 01 May '10

01 May '10

Hi, just some changes and cleanups according the still ongoing discussion on ldapext. The patch can be downloaded here: ftp://ftp.openldap.org/incoming/daniel-pluta-100501.patch Changes: - removed extensible matching rules strictly associated with dedicated syntaxes - added two universal matching rules instead: - nowMach (equality matching rule) - nowOrdering (ordering matching rule) - these two rules also support extensible match filters To publish a correct server current time time-stamp value within Root-DSE: - apply the bugfix from ITS#6541 - and use -DCTM_G_DIFFERENTIAL_SERVERTIME To extend generalizedTime attribute types to also support "NOW" as assertion value: - use -DCTM_RFC4517_MR_AV_SYNTAX_VIOLATION Beware of patching conflicts in schema_init.c: This patch contains small redundant parts from my parallel contribution in ITS#6532 Regards, Daniel

1 0

(ITS#6541) liblutil/ultils.c: lutil_localtime() <g-differential> timestamp format bug
by daniel＠pluta.biz 01 May '10

01 May '10

Full_Name: Daniel Pluta Version: HEAD OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:9feb:ff02:91d5:32:f2b:def0) Hi, for a description and a possible patch (to small for an upload ;-)) please see: http://www.openldap.org/lists/openldap-devel/201003/msg00012.html Cheers

1 0

Re: (ITS#6534) bad ifdef/elif clause in liblutil
by h.b.furuseth＠usit.uio.no 30 Apr '10

30 Apr '10

quanah(a)zimbra.com writes: > Actually, the issue seems to be name changes in the header files under BSD. > This causes TIOCNOTTY to end up being undefined. That would not give the error message shown in <http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg776021.html>: build/buildd-openldap_2.4.21-1-kfreebsd-amd64-VWAqZY/openldap-2.4.21/libraries/liblutil/detach.c:131:7: error: missing binary operator before token "long" Line 131 is "#elif TIOCNOTTY". There's no 'long' there is TIOCNOTTY is undefined, it'd just evaluate to #elif 0. So my guess is that TIOCNOTTY somewhere is defined to expand to an expression involving a (long) cast. -- Hallvard

1 0

Re: (ITS#6456) Feature Request
by j＠gropefruit.com 29 Apr '10

29 Apr '10

It works exactly as I had hoped. Thank you for implementing this, I = believe it will be an asset to others besides myself. J > This is now implemented in back-ldap (idassert-passthru, = olcDbIDAssertPassThru, undocumented yet). > Basically, identities matching rules formally identical to those of = idassert-authz=46rom do not undergo identity assertion. =20 > This rule is checked before idassert-authzFrom, so in case an identity = matches both, passthru wins. Please test and report. > p.=20

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by quanah＠zimbra.com 29 Apr '10

29 Apr '10

--On Thursday, April 29, 2010 5:38 PM +0000 ryans(a)aweber.com wrote: > Great, many thanks for your efforts in confirming. Just out of > curiosity, when the fix is actually committed, will the commit number or > source code file be present in the ITS, so that one can easily > cross-reference the ITS with a particular file or set of files from CVS > HEAD? And again, please let me know if there's anything I can do to help > facilitate the process, or make it easier for you and/or the other > developers. I'm happy to test, patch the test scripts, et cetera. Unfortunately no, that type of commit -> bug integration does not currently exist, although I think it is a highly desirable feature and one that has been discussed for implementation. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs