h.b.furuseth@usit.uio.no wrote:
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.
Hm, I think I see what you mean, but I don't see what to do about that.
ldap://111.222.333.444:389??cn=abc,o=company -> error 5 (LDAP_URL_ERR_BADURL)
This now works.
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
This now works.
================
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.
This now works.
Also, what does stuff between the ']' and ':port' mean? Should anything be allowed there?
ldap://[::1]what's this:222/ -> host "::1", port 222 ->
This is now correctly rejected.
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
I've left this alone for now.
================
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.
This is a mess. The ldap: scheme definition has always been broken, and it certainly does not conform to the basic URI syntax in RFC3986 section 3. In particular, RFC3986 forbids a URI from containing "//" when the authority component is absent. Looks like RFC4516 should not have been approved in its current state.
================
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.
I thought about changing this, but left it alone for now. Agreed, the interaction with ldap.conf isn't clear.
================
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)
These are all fixed. Note that the "ldapi:///tmp/foo:222/" case simply means an ldapi:// URL with a DN of "tmp/foo:222/" which is legal in a URL parsing sense, even though DN validation would reject it.
====
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
These are all fixed.