[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
(ITS#4879) URL parse/unparse troubles
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