openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#6247)
by masarati＠aero.polimi.it 13 Aug '09

13 Aug '09

> masarati(a)aero.polimi.it wrote: >> As I mentioned in an earlier posting, any generalizedTime-syntax >> attribute >> can use your special matching rules by way of the extensible filter >> mechanism, regardless of having any matching rule in their definition. >> > I thought, that by not assigning any matching rule the EQ/LE/GE > comparison is not possible at all. That's the behavior I would like to > achieve regarding the two minimum-attributes (regardless whether the > probable separation of matching rules and attribute definitions - > disscussed in the above paragraphs). By not assigning a matching rule, that specific matching is not possible using normal filters. However, the extensible filter mechanism overrides this, by allowing to specify the desired matching rule in the AVA. > Yesterday I've noticed that without an EQ-Matching definition I was not > able to add an additional value in case of a multi-valued attribute > definition (so I added EQ-Matching again). I have to admit that I do not > understand this in detail. I also have not investigated in deep... That's a totally different business. If you do not define an equality matching rule, multiple values cannot be checked for duplicates. So the only way to add a value consists in performing a modify:delete and a modify:add within the same modify operation that removes the original values and replaces them with themselves plus the new ones. >> Moreover, attributes can already be defined using >> slapd.conf/back-config, >> so there's no need to hardcode them in your module (except, possibly, >> for >> your specific needs, but this makes the module less general and useful >> to >> others). >> > The oc/attr definition is for demonstration purposes only (I though it's > more compact to include this "demo" and implement it the most restricted > way regard data privacy (especially disallow querying LE/GE for both > attr). > Problably I'll separate the demo into an extra schema file. You should. Please note that for the purpose of testing your code, every entry already has a createTimestamp and a modifyTimestamp attribute. >> But >> the real reason is that "exactly equal to now" makes little sense as >> "now" >> is evanescent: you have no control about exactly when your matching rule >> > hehe that relativistic effects I already had in mind before implementing > this kind of matching rule. That's the reason I originally followed the > approach to manipulate the search requests' filters. This approach could > assure to make use of the "same" now (op->o_time) for all entries. Well, this calls for an extension of the matching API that also passes the Operation pointer. Something for 2.5, if worth the effort (note that value matching and operations are orthogonal, as value matching can also occur outside the scope of a LDAP operation, so passing that pointer would basically be a matter of opportunity if matching rule implementations need it). > By using the matching rule (especially in combination with the filter= > statement in ACLs) "now" will become some kind of "time distance" > instead of a point in time because a search' results get evaluated > sequentially by test_filter(). > > In worst case the second have of a billion search entries are valid > during the search but get "invalid" during acl processing, because time > move's on... ;-) > > On the other side comparing the lines of code of the matching rule > approach to my previous pre-alpha overlay's lines of code, this matching > rule's implementation is about 10 times smaller... If you follow my advice, it'll be 100 times smaller :) >> will be evaluated, so if the difference between "including now" or >> "excluding now" is crucial, then there might be something flawed in the >> policy you're trying to implement. >> > Ok, this in mind I'll at least reduce the matching rules to two but the > problem (now == time_delta) still exists. I concur. >> Getting more into implementation related aspects, I think you should >> really ignore the asserted value, rather than check it's equal to the >> Epoch. I initially suggested to put the Epoch as the asserted value in >> order to use some clearly recognizable, yet valid, value. But this >> should >> be a matter of style rather than a requirement of the matching rule. >> > I regard to some kind of future formal specification I thought about > this, too: in my opinion it seems to be "unnatural" to search (assert) a > non-Timestamp-value to a generalizedTimestamp-Syntax attribute... But > probably that's really only a matter of style. I'm not sure I understand what you mean here. If you mean that anything could fit as the asserted value, this is not correct, because LDAP requires the asserted value to comply with the syntax of the matchingRule. Of course one could define a syntax for asserting generalizedTime values that consists in the empty string, so that (createTimestamp:laterThanNow:=) is a valid filter (note the empty asserted value). >> With respect to OID assignment, as soon as your contribution is >> considered >> of general usefulness, it could receive a temporary OID out of >> OpenLDAP's >> experimental branch. If you intend to formalize this set of matching >> rules somehow, you should apply for IANA assignment of an official OID. >> >> Note that I'm not encouraging nor discouraging you in this sense. >> > I'm currently thinking about this... > > Thanks for your feedback the discussion is very interesting and helpful. p.

1 0

Re: (ITS#6247)
by daniel＠pluta.biz 13 Aug '09

13 Aug '09

masarati(a)aero.polimi.it wrote: >> Hi, >> >> I've just uploaded an updated version. >> >> Changes regarding schema: >> - Added EQ-Matching rule to both nowNot{Before|After} attributes >> - changed attribute nowNotAfter from single- into multi-value >> >> ftp://ftp.openldap.org/incoming/daniel-pluta-now-090812.tgz >> > > In order to make your contribution useful to others, I think you should > definitely separate comparison with respect to current time from the rest > of what you need. > In this sense, special matching rules to compare generalizedTime-syntax > attributes with respect to "now" have nothing to do with the declaration > of specific generalizedTime-valued attributes. > I've already thought about this. I'm in two minds about that. > As I mentioned in an earlier posting, any generalizedTime-syntax attribute > can use your special matching rules by way of the extensible filter > mechanism, regardless of having any matching rule in their definition. > I thought, that by not assigning any matching rule the EQ/LE/GE comparison is not possible at all. That's the behavior I would like to achieve regarding the two minimum-attributes (regardless whether the probable separation of matching rules and attribute definitions - disscussed in the above paragraphs). Yesterday I've noticed that without an EQ-Matching definition I was not able to add an additional value in case of a multi-valued attribute definition (so I added EQ-Matching again). I have to admit that I do not understand this in detail. I also have not investigated in deep... > Moreover, attributes can already be defined using slapd.conf/back-config, > so there's no need to hardcode them in your module (except, possibly, for > your specific needs, but this makes the module less general and useful to > others). > The oc/attr definition is for demonstration purposes only (I though it's more compact to include this "demo" and implement it the most restricted way regard data privacy (especially disallow querying LE/GE for both attr). Problably I'll separate the demo into an extra schema file. > But > the real reason is that "exactly equal to now" makes little sense as "now" > is evanescent: you have no control about exactly when your matching rule > hehe that relativistic effects I already had in mind before implementing this kind of matching rule. That's the reason I originally followed the approach to manipulate the search requests' filters. This approach could assure to make use of the "same" now (op->o_time) for all entries. By using the matching rule (especially in combination with the filter= statement in ACLs) "now" will become some kind of "time distance" instead of a point in time because a search' results get evaluated sequentially by test_filter(). In worst case the second have of a billion search entries are valid during the search but get "invalid" during acl processing, because time move's on... ;-) On the other side comparing the lines of code of the matching rule approach to my previous pre-alpha overlay's lines of code, this matching rule's implementation is about 10 times smaller... > will be evaluated, so if the difference between "including now" or > "excluding now" is crucial, then there might be something flawed in the > policy you're trying to implement. > Ok, this in mind I'll at least reduce the matching rules to two but the problem (now == time_delta) still exists. > Getting more into implementation related aspects, I think you should > really ignore the asserted value, rather than check it's equal to the > Epoch. I initially suggested to put the Epoch as the asserted value in > order to use some clearly recognizable, yet valid, value. But this should > be a matter of style rather than a requirement of the matching rule. > I regard to some kind of future formal specification I thought about this, too: in my opinion it seems to be "unnatural" to search (assert) a non-Timestamp-value to a generalizedTimestamp-Syntax attribute... But probably that's really only a matter of style. > With respect to OID assignment, as soon as your contribution is considered > of general usefulness, it could receive a temporary OID out of OpenLDAP's > experimental branch. If you intend to formalize this set of matching > rules somehow, you should apply for IANA assignment of an official OID. > > Note that I'm not encouraging nor discouraging you in this sense. > I'm currently thinking about this... Thanks for your feedback the discussion is very interesting and helpful.

1 0

Re: (ITS#6140) nadf.schema: AttributeType not found: "lastModifiedTime"
by michael＠stroeder.com 13 Aug '09

13 Aug '09

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> So it seems the relevance of this schema to anything in use today is >> about nil. > >> If you can find any current, active organizations with a currently maintained >> spec for this schema, we can certainly update it. Otherwise, seems like we >> should drop it. > > There is still an archive of the NADF documents here > http://stats.dante.org.uk/nameflow/ds/nadf.html > > but again, the very difficulty in locating them tends to indicate that they're > not in common use... I'd have no objections against removing that file from OpenLDAP's source distribution. I was just testing including as many schema files as possible and checking dependencies (for interop testing with web2ldap). Ciao, Michael.

1 0

Re: (ITS#6247)
by masarati＠aero.polimi.it 13 Aug '09

13 Aug '09

> Hi, > > I've just uploaded an updated version. > > Changes regarding schema: > - Added EQ-Matching rule to both nowNot{Before|After} attributes > - changed attribute nowNotAfter from single- into multi-value > > ftp://ftp.openldap.org/incoming/daniel-pluta-now-090812.tgz In order to make your contribution useful to others, I think you should definitely separate comparison with respect to current time from the rest of what you need. In this sense, special matching rules to compare generalizedTime-syntax attributes with respect to "now" have nothing to do with the declaration of specific generalizedTime-valued attributes. As I mentioned in an earlier posting, any generalizedTime-syntax attribute can use your special matching rules by way of the extensible filter mechanism, regardless of having any matching rule in their definition. Moreover, attributes can already be defined using slapd.conf/back-config, so there's no need to hardcode them in your module (except, possibly, for your specific needs, but this makes the module less general and useful to others). Finally, I don't think having both a "(<)" and a "(<=)" rule makes sense. LDAP only defines "(<=)" since one may construct "<" as "(!(>=))". But the real reason is that "exactly equal to now" makes little sense as "now" is evanescent: you have no control about exactly when your matching rule will be evaluated, so if the difference between "including now" or "excluding now" is crucial, then there might be something flawed in the policy you're trying to implement. Getting more into implementation related aspects, I think you should really ignore the asserted value, rather than check it's equal to the Epoch. I initially suggested to put the Epoch as the asserted value in order to use some clearly recognizable, yet valid, value. But this should be a matter of style rather than a requirement of the matching rule. With respect to OID assignment, as soon as your contribution is considered of general usefulness, it could receive a temporary OID out of OpenLDAP's experimental branch. If you intend to formalize this set of matching rules somehow, you should apply for IANA assignment of an official OID. Note that I'm not encouraging nor discouraging you in this sense. p.

1 0

(ITS#6253) sizelimit is enforced before applying local filters with a translucent overlay
by isaac＠ebox-platform.com 13 Aug '09

13 Aug '09

Full_Name: Isaac Clerencia Version: 2.4.15 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.198.40.13) If a 'sizelimit' is required in a query to an LDAP server that uses a translucent overlay, and the filter has to be split between a remote filter and a local filter, and the remote filter returns more than 'sizelimit' objects, you will get a 'sizelimit' error even if the local filter would have filtered out enough objects to keep the number of objects under the sizelimit. In my case I have an LDAP holding basic posixAccount information plus a translucent holding Samba information. The following query: % ldapsearch -z 1 -x -s one -b 'ou=Users,dc=hq,dc=eboxhq,dc=com' -H 'ldap://127.0.0.1:1390' '(&(objectClass=posixAccount)(sambaSID=S-1-5-21-3818554400-921237426-3143208535-5004))' uid only matches one object in the LDAP directory, but it will fail because the remote LDAP will return every user and then the 'sizelimit' is immediately enforced before applying the local (sambaSID) filter. The result with -z 1 is: # search result search: 2 result: 4 Size limit exceeded # numResponses: 1 The result without the -z option is: # bar, Users, hq.eboxhq.com dn: uid=bar,ou=Users,dc=hq,dc=eboxhq,dc=com uid: bar # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 I think the 'sizelimit' should only be applied to the last set of results and not to the number of results in intermediate steps.

1 0

Re: (ITS#6140) nadf.schema: AttributeType not found: "lastModifiedTime"
by hyc＠symas.com 13 Aug '09

13 Aug '09

hyc(a)symas.com wrote: > So it seems the relevance of this schema to anything in use today is > about nil. > If you can find any current, active organizations with a currently maintained > spec for this schema, we can certainly update it. Otherwise, seems like we > should drop it. There is still an archive of the NADF documents here http://stats.dante.org.uk/nameflow/ds/nadf.html but again, the very difficulty in locating them tends to indicate that they're not in common use... -- -- 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

Re: (ITS#6140) nadf.schema: AttributeType not found: "lastModifiedTime"
by hyc＠symas.com 13 Aug '09

13 Aug '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: RE24 > OS: Linux > URL: > Submission from: (NULL) (84.163.124.107) > > > When including nadf.schema slapd does not start and prints error message: > > /opt/openldap-RE24/etc/openldap/schema/nadf.schema: line 111 objectclass: > AttributeType not found: "lastModifiedTime" > /etc/openldap/slapd.conf: line 17:<include> handler exited with 1! > > Analyzing this I found this commented declaration in cosine.schema: > > ## Deprecated in favor of modifyTimeStamp > #attributetype ( 0.9.2342.19200300.100.1.23 NAME 'lastModifiedTime' > # DESC 'RFC1274: time of last modify, replaced by modifyTimestamp' > # OBSOLETE > # SYNTAX 1.3.6.1.4.1.1466.115.121.1.53 > # USAGE directoryOperation ) > > So it seems nadf.schema is not usable at the moment. The comments in the file already state "intended to be used with QUIPU/X.500 and not LDAPv3". Not sure what the point is to maintaining this file any further, the NADF was absorbed by the EMA (Electronic Messaging Association) in 1996[1] and as far as I can see, the EMA has vanished from the web. (www.ema.org now directs to a porn directory here; apparently my network provider Time-Warner is hijacking NXDOMAINs...) [1] http://archive.dante.net/upload/pdf/NameFLOW_Report_1996_Q1.pdf page 31 The X.500 directory structure that the NADF was created to promote was superseded by the DNS-based directory hierarchy proposed in RFC2377 back in 1998. So it seems the relevance of this schema to anything in use today is about nil. If you can find any current, active organizations with a currently maintained spec for this schema, we can certainly update it. Otherwise, seems like we should drop it. -- -- 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

Re: (ITS#6251) GnuTLS cipher suite failure
by hyc＠symas.com 13 Aug '09

13 Aug '09

hyc(a)symas.com wrote: > In fact, the list must be colon separated, and the "+" is required. Just > listing the name will cause an error. Also, the actual suite names cannot be > used, only the individual algorithm names are recognized. So instead of the > suite name "TLS_RSA_AES_256_CBC_SHA1" you must specify "+AES-256-CBC:+SHA1". To be precise, you must specify "+RSA:+AES-256-CBC:+SHA1". > This method is more error-prone, because it makes it possible to specify a > list of algorithms that do not conform to any valid suite. > > All in all, it may be best to revert back to using our own suite parser and > ignore the one GnuTLS provides. -- -- 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

Re: (ITS#6252) GnuTLS subjectAltNames broken
by hyc＠symas.com 13 Aug '09

13 Aug '09

hyc(a)symas.com wrote: > The bug was reported against Ubuntu jaunty originally, and still exists in > current GnuTLS git. So it appears to affect at least 2.4.2-present. The fix is > trivial and is attached below. I will also submit this to the GnuTLS bug tracker. This is https://savannah.gnu.org/support/index.php?106975 -- -- 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

Re: (ITS#6252) GnuTLS subjectAltNames broken
by hyc＠symas.com 13 Aug '09

13 Aug '09

This is a multi-part message in MIME format. --------------060905090106040506040806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.17 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > GnuTLS fails to parse certain subjectAltNames and returns spurious SHORT_BUFFER > error. > > We passed in a buffer size of 1025, and it's internally overwriting it with a > size of only 31 and then complaining that 31 is too small > The bug was reported against Ubuntu jaunty originally, and still exists in current GnuTLS git. So it appears to affect at least 2.4.2-present. The fix is trivial and is attached below. I will also submit this to the GnuTLS bug tracker. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------060905090106040506040806 Content-Type: text/x-patch; name="0001-Fix-XMPP-parsing.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Fix-XMPP-parsing.patch" >From 436824d8b8a908860688354841b4b082d4239157 Mon Sep 17 00:00:00 2001 From: Howard Chu <hyc(a)symas.com> Date: Wed, 12 Aug 2009 15:48:02 -0700 Subject: [PATCH] Fix XMPP parsing --- lib/x509/x509.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/lib/x509/x509.c b/lib/x509/x509.c index 048ff89..e15531e 100644 --- a/lib/x509/x509.c +++ b/lib/x509/x509.c @@ -1011,6 +1011,7 @@ _gnutls_parse_general_name (ASN1_TYPE src, const char *src_name, return _gnutls_asn2err (result); } + len = *name_size; result = asn1_read_value (c2, "", name, &len); *name_size = len; if (result != ASN1_SUCCESS) -- 1.6.3.rc3 --------------060905090106040506040806--

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