[Exim] Documentation error - quote_ldap example

Pàgina inicial
Delete this message
Reply to this message
Autor: Brian Candler
Data:  
A: exim-users
Assumpte: [Exim] Documentation error - quote_ldap example
I would like to point out a bug in one of the examples in the documentation,
which also raises a functionality issue.

In section 33.3, the following example is given for ldapauth:

    server_condition = ${if ldapauth \
      {user="uid=${quote_ldap:$1},ou=people,o=example.org" \
      pass="$2" \
      ldap://ldap.example.org/}{yes}{no}}


The problem is that ${quote_ldap:$1} is the wrong thing to do here. The
user=... parameter is not in fact part of a URL, and therefore is not
subject to URL quoting rules. In particular, this example rewrites
"foo@???" to "foo%40example.com", and as I just found out, this
causes the LDAP bind to fail.

The username is, however, a distinguished name. Unfortunately, there are
three different sets of quoting rules for LDAP :-(

1. Distinguished Names

The following characters appearing within a DN are escaped by preceeding
them with a backslash:
     , + " \ < > ;


In addition, a space at the beginning or end of the DN, and a # at the
beginning of the DN, must also be preceeded with a backslash.

So rather than use quote_ldap, a closer approximation is achieved with
something like this:

user="uid=${sg{$1}{([,+\"\\<>;])}{\\\\\$1}},ou=people,o=example.org"

However that's messy, so maybe there's an argument for adding a quote_dn
operator.

2. Search filters

   *   is rewritten as \2A
   (          "        \28
   )          "        \29
   \          "        \5C
   NUL        "        \00


So if you were writing a search on (uid=$1) you would have to use these
rules instead.

3. URLs

If you are writing LDAP searches as RFC2255 URLs then they are in addition
subject to normal URL escaping (which is where @ -> %40 came from)

The Exim documentation says:

"For LDAP quoting, the characters #,+"\<>;*() have to be preceded by a
backslash. (In fact, only some of these need to be quoted in Distinguished
Names, and others in LDAP filters, but it does no harm to have a single
quoting rule for all of them.)"

But if I understand the specs, it's not actually correct to rewrite * as \*
in a search filter; RFC2254 section 4 says it should be \2A. The behaviour
of \* appears to be undefined; it's possible that it works with some common
LDAP servers, but it's not the right thing to do.

It seems to me that it's not possible to have one function which does both
DN and search filter quoting. In particular, a backslash is rewritten as
'\\' in the first case and '\5C' in the second.

Furthermore, a DN may appear within a URL (e.g. as the search base) in which
case it is subject to URL quoting, or it may appear as a USER parameter in
which case it isn't.

A mess, isn't it? :-)

Cheers,

Brian.