openldap-bugs

openldap-bugs@openldap.org

1 participants
21304 discussions

(ITS#4879) URL parse/unparse troubles
by h.b.furuseth＠usit.uio.no 17 Mar '07

17 Mar '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard Here are some URLs parsing/building bugs in libldap/url.c. Some may be design bugs. Possibly some fixes will need backwards bug-compatibility. I show URLs converted from string to LDAPURLDesc format with ldap_url_parse(), back to string format with ldap_url_desc2str() when the result differs from the original, back to LDAPURLDesc... ================ The url.c Novell kludge does not work (for the example URL). If the bug is old and nobody has complained, maybe it should be removed. If it's fixed instead, note that the code looks like it'll handle Novell URLs with '/' in components after hostport: ldap_url_parse_ext() does strchr( url, '/' ) very early to find the end of the hostport. ldap://111.222.333.444:389??cn=abc,o=company -> error 5 (LDAP_URL_ERR_BADURL) Example URL without port number: ldap://111.222.333.444??cn=abc,o=company -> host "111.222.333.444??cn=abc,o=company", DN NULL -> ldap://111.222.333.444??cn=abc,o=company:389/??base ================ ldap_url_desc2str() outputs IPv6 host addresses as "addr" rather than "[addr]". (LDAPURLDesc does not contain the '[]'s in .lud_host, nor any flag which says it's an IPv6 host address). I don't know the syntax of such addresses, but I seem to remember they contains ':'s. If so the parser could fail if an IPv6 address does not contains ':', and the URL builder could test for ':' to determine if there should be [] around the host part. Also, what does stuff between the ']' and ':port' mean? Should anything be allowed there? ldap://[::1]what's this:222/ -> host "::1", port 222 -> ldap://::1:222/??base -> error 5 (LDAP_URL_ERR_BADURL) ================ Converting "%00" to char* should return an error, since the char* will not match the source URL: ldapi://a%00b/cn=d%00e -> host "a", DN "cn=d" -> ldapi://a/cn=d??base ================ The RFCs 4516/2255 hostport part has grammar [host [":" port]], but ldap_url_desc2str() produces [host][":" port]. ldap:// -> host NULL, port 389 -> ldap://:389/??base That's OK as an ldap_url_parse() OpenLDAP extension, but not as ldap_url_desc2str() output given to non-OpenLDAP applications. ================ While I'm writing, I wonder if OpenLDAP 2.4 could omit defaults and final "?"s from the ldap_url_desc2str() output. E.g. ldap:// would become ldap:// and not ldap://:389/??base. But maybe we get into trouble if ldap.conf has another port or something. ================ ldapi URL (un)parsing has several problems: ldap_url_parse() always treats ':' as a host:port separator. Thus one can produce an ldapi LDAPURLDesc with a meaningless port. However ldap_url_desc2str() does not URL-escape ':', and it also takes port!=0 to mean it is not an ldapi URL and needs no '/'-escaping. Similarly filenames with initial '[' do not work. ldapi://%2Ftmp%2Ffoo%3A222/ -> host "/tmp/foo:222" (correct) -> ldapi://%2Ftmp%2Ffoo:222/??base -> host "/tmp/foo", port 222 -> ldapi:///tmp/foo:222/??base -> host NULL, DN "tmp/foo:222/" ldapi://%2Ftmp%2Ffoo:000/ -> host "/tmp/foo" -> ldapi://%2Ftmp%2Ffoo/??base ldapi://%2Ftmp%2Ffoo:bar/ -> error 5 (LDAP_URL_ERR_BADURL) ==== The current implementation would handle some non-Unix ldapi filenames wrong. (They'll need well-defined URL-escaping rules if they get implemented, so it might as well be fixed now.) Of course these can also be strange Unix relative filenames... Windows-like filenames: ldapi://C%3A%2Fldapi/ -> host "C:/ldapi" -> ldapi://C:%2Fldapi/??base -> error 5 (LDAP_URL_ERR_BADURL) Tops-20-like filenames resemble IPv6 addresses (not that I expect to port OpenLDAP to Tops-20:-) ldapi://[ldap.var.run]ldapi/ -> host "ldap.var.run" -> ldapi://ldap.var.run/??base URL-escaping the '[' and ']' does not help; the '[' is lost: ldapi://%5Bldap.var.run%5Dldapi/ -> host "ldap.var.run]ldapi" -> ldapi://ldap.var.run%5Dldapi/??base

1 0

Re: (ITS#4872) Non-portable comparison in wait4msg() (result.c) causes infinite loop
by ando＠sys-net.it 17 Mar '07

17 Mar '07

There might be more about this; in daemon.c, difftime() is used to compute the difference between two time_t, but the result is assigned to a time_t. Maybe a negative value cannot be obtained, but in any case that cast would likely be incorrect as well in systems where time_t is unsigned. I'm re-opening this bug. 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#4878) removal of duplicate variables in slapd
by ando＠sys-net.it 17 Mar '07

17 Mar '07

bret.lambert(a)gmail.com wrote: > Unnecessary duplicate variables using the same name have been removed with this > patch. > > Found via lint(1) on OpenBSD. 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

(ITS#4878) removal of duplicate variables in slapd
by bret.lambert＠gmail.com 17 Mar '07

17 Mar '07

Full_Name: bret lambert Version: HEAD OS: OpenBSD URL: ftp://ftp.openldap.org/incoming/bret-lambert-070317.patch.1 Submission from: (NULL) (70.179.123.124) Unnecessary duplicate variables using the same name have been removed with this patch. Found via lint(1) on OpenBSD.

1 0

Re: (ITS#4868) Binary Attribute Patch(es)
by ando＠sys-net.it 14 Mar '07

14 Mar '07

Kevin Vargo wrote: > So, in ad.c [ad_inlist], the AttributeDescription (*desc) does not > have it's flags set 'properly.' That is, apparently within that > structure there are flags and tags, during the parsing of the schema, > the flags and tags get set properly (same file [slap_bv2ad]): > desc.ad_flags |= SLAP_DESC_BINARY; > > That means that, in ad_inlist, the desc's name still has ";binary" in > it, and no flags set. I find that if I map this condition as an > entry in the if/else cascade -- right after checking the flags, but > before the if-fail on flag compare -- the data is properly returned. > (I'll generate a patch, if that's an appropriate thing to do/place to > do it.) Not sure I understood - waiting for your patch... > However, there remains a problem: other LDAP Servers appear to return > the 'attribute-name' requested (userCertificate;binary::) to describe > the data. Now that the data is being returned, it's being returned > without the ";binary" option -- as 'userCertificate::'. Per > ITS#3113, ";binary" is obsoleted? To be honest, I'm not sure I have ever clearly understood that ";binary" issue, and I don't have time to dig out the documentation, learn about it, and check the code, since the whole stuff seems to be obsolete. > Is there a compatibility mode that can be optioned to support this? None that I know of. > Obsoleted and back-wards compatibility being in conflict..... I think compatibility with obsolete stuff is something that may easily get in conflict with open source, volunteer developed software. Volunteers tend to concentrate scarce resources on important things, and preserving compatibility with obsolete (often broken) stuff is first of all a waste of scarce resources, and second, but not least, reduces pressure on obsolete (broken) software makers, which typically are not volunteers but actually get paid for (obsolete/broken stuff). Having said this, you may find volunteers that, pushed by their own needs like to spend time supporting obsolete/broken stuff for the simple reason they need it. > i.e. > is there a way to say "return the attribute by name-requested instead > of schema-name?" No. This question has been raised many times, and the answer has always been like that. All you could do is hack slap_send_search_entry() in servers/slapd/result.c. 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#4868) Binary Attribute Patch(es)
by vargok＠yahoo.com 14 Mar '07

14 Mar '07

So, in ad.c [ad_inlist], the AttributeDescription (*desc) does not have it's flags set 'properly.' That is, apparently within that structure there are flags and tags, during the parsing of the schema, the flags and tags get set properly (same file [slap_bv2ad]): desc.ad_flags |= SLAP_DESC_BINARY; That means that, in ad_inlist, the desc's name still has ";binary" in it, and no flags set. I find that if I map this condition as an entry in the if/else cascade -- right after checking the flags, but before the if-fail on flag compare -- the data is properly returned. (I'll generate a patch, if that's an appropriate thing to do/place to do it.) However, there remains a problem: other LDAP Servers appear to return the 'attribute-name' requested (userCertificate;binary::) to describe the data. Now that the data is being returned, it's being returned without the ";binary" option -- as 'userCertificate::'. Per ITS#3113, ";binary" is obsoleted? Is there a compatibility mode that can be optioned to support this? Obsoleted and back-wards compatibility being in conflict..... i.e. is there a way to say "return the attribute by name-requested instead of schema-name?" ----- Original Message ---- From: Kevin Vargo <vargok(a)yahoo.com> To: Pierangelo Masarati <ando(a)sys-net.it> Cc: openldap-its(a)openldap.org Sent: Tuesday, March 13, 2007 10:15:26 AM Subject: Re: (ITS#4868) Binary Attribute Patch(es) >----- Original Message ---- >From: Pierangelo Masarati <ando(a)sys-net.it> >To: vargok(a)yahoo.com >Cc: openldap-its(a)openldap.org >Sent: Monday, March 12, 2007 4:52:04 PM >Subject: Re: (ITS#4868) Binary Attribute Patch(es) > > >> These address the use of Binary-valued attributes (#3113, #3386): >> >> For example, inetOrgPerson.userCertificate is usually transferred with the >> ";binary" directive. ";binary" is not handled by OpenLDAP/Back-SQL. > >Well, the solution you propose is not correct, since you are altering >schema data, which is supposed to be read-only. In any case, the point is: Yeah; I think the actual submission found the ";binary" and reset the reference to it, not actually doing anything to it. >- if we decide that back-sql should ignore tags, then the solution >consists in using the canonical name of the underlying AttributeType >when looking up data; > >- however, this would destroy the possibility to use different storages >for differently encoded data; for example, a column for "cn;lang-en" and >a column for "cn;lang-jp". I don't know how many users would prefer one >solution over another, but in any case either we find a solution that >preserves both capabilities or we choose one. I'd vote in favor of >ignoring ";binary" since it's obsolete and related to transport only, >but in favor of honoring language tags. Sounds great to me. I just want support for ";binary" both on storage and retrieval to be supported. I'll accept that it's obsolete -- I'll also put forth that a lot of things still use it (e.g. Lotus Domino v6). >> There remains an issue with selecting attributes using, e.g., >> "userCertificate;binary" -- nothing is returned. Someone with a better >> understanding of the attribute-processing method would be much more effective in >> terms of finding the correct place to remove the ";binary" from the >> "attribute-name." (i.e. "userCertificate;binary" is NOT the attribute-name; >> "userCertificate" is the attribute-name, ";binary" is a transport directive (see >> #3113). > >In fact, "userCertificate;binary" is the attribute description. The >attribute name is in ad_type->sat_cname. And, in fact, none of what I did appears to have been sufficient. I'm still looking at why selecting "userCertificate;binary" as part of an ldapsearch attribute-list doesn't pull the data. "userCertificate" does. The issue appears to be related to the ad_inlist verification on the search-supplied attribute -- "userCertificate;binary" doesn't resolve. If you know where I can look to figure this out, that would help. I've been through some areas and not found exactly where just yet. Thanks for your assistance. Kevin Vargo ____________________________________________________________________________________ The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php ____________________________________________________________________________________ Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html

1 0

Re: (ITS#4869) config creates base64 encoded rootdn
by hyc＠symas.com 14 Mar '07

14 Mar '07

You should have provided this information in the original report. This is a dup of ITS#4848, already fixed in HEAD. In the mean time, don't interleave overlay statements with database statements. Dieter Kluenter wrote: > I just deleted slapd.d and rerun slapd -F -f, this is the relevant output of > olcDatabase={1}hdb.ldif > > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcRootDN:: cBcAAGRtaW4sbz1hdmNpLGM9ZGU= > olcRootPW:: aGhkeTAx > olcMonitoring: TRUE > olcDbDirectory: /var/lib/ldap > olcDbCacheSize: 1000 > olcDbCheckpoint: 1024 5 > olcDbConfig: {0}set_cachesize 0 268435456 1 > > and this is part of the slapd.conf in question > > ######### databases ############ > database config > rootdn cn=config > rootpw hhdy01 > # > database hdb > suffix "o=avci,c=de" > rootdn "cn=admin,o=avci,c=de" > rootpw xxxxx > # > overlay dynlist > dynlist-attrset groupOfURLs memberURL > # > checkpoint 1024 5 > cachesize 2000 > idlcachesize 6000 > ... > ... > > -Dieter > -- -- Howard Chu Chief Architect, 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#4869) config creates base64 encoded rootdn
by dieter＠dkluenter.de 14 Mar '07

14 Mar '07

Howard Chu <hyc(a)symas.com> writes: > dieter(a)dkluenter.de wrote: >> Howard Chu <hyc(a)symas.com> writes: >> >>> What is the original rootdn? >>> >> cn=admin,o=avci,c=de >> -Dieter >> > I don't see anything like that here. You'll probably have to post your > slapd.conf. Have you checked for extraneous white space in the > original rootdn config? I just deleted slapd.d and rerun slapd -F -f, this is the relevant output of olcDatabase={1}hdb.ldif olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN:: cBcAAGRtaW4sbz1hdmNpLGM9ZGU= olcRootPW:: aGhkeTAx olcMonitoring: TRUE olcDbDirectory: /var/lib/ldap olcDbCacheSize: 1000 olcDbCheckpoint: 1024 5 olcDbConfig: {0}set_cachesize 0 268435456 1 and this is part of the slapd.conf in question ######### databases ############ database config rootdn cn=config rootpw hhdy01 # database hdb suffix "o=avci,c=de" rootdn "cn=admin,o=avci,c=de" rootpw xxxxx # overlay dynlist dynlist-attrset groupOfURLs memberURL # checkpoint 1024 5 cachesize 2000 idlcachesize 6000 ... ... -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

(ITS#4877) Patch to ldapmodrdn.1
by daveh＠ci.com.au 13 Mar '07

13 Mar '07

Full_Name: Dave Horsfall Version: HEAD OS: FreeBSD 6.2 URL: ftp://ftp.openldap.org/incoming/dave-horsfall-070314.patch Submission from: (NULL) (192.65.182.30) Trivial patch to ldapmodrdn.1 to document "-s newsup".

1 0

(ITS#4876) Multiple levels of uniqueness
by quanah＠stanford.edu 13 Mar '07

13 Mar '07

Full_Name: Quanah Gibson-Mount Version: 2.3.33 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) In using the uniqueness overlay, I found there are times I want to apply uniqueness rules differently based on (sub)tree. For example, I might like something along these lines where the db starts at dc=stanford,dc=edu: overlay unique unique_base dc=stanford,dc=edu unique_attributes krb5PrincipalName suRegID overlay unique unique_base cn=people,dc=stanford,dc=edu unique_attributes suunivid suproxycardnumber sucardnumber suuniqueidentifier overlay unique unique_base cn=accounts,dc=stanford,dc=edu unique_attributes uid However, I found in testing this, that any instantiation of the uniqueness overlay past the first one is ignored (i.e., not applied to writes). I think being able to do this is useful, becase I only want the uniqueness overlay to intercede when the write applies to the particular (sub)tree where it is necessary to enforce it. It may be worthwhile to update the syntax for the uniqueness overlay to behave more like the valsort overlay, where each attribute defines which tree it is applying weights to, like: overlay valsort valsort-attr ou cn=people,dc=stanford,dc=edu weighted valsort-attr suAffiliation cn=people,dc=stanford,dc=edu weighted valsort-attr suDisplayAffiliation cn=people,dc=stanford,dc=edu weighted --Quanah

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs