Re: [Exim] Documentation error - quote_ldap example

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Brian Candler
Ημερομηνία:  
Προς: exim-users
Αντικείμενο: Re: [Exim] Documentation error - quote_ldap example
On Mon, Aug 19, 2002 at 09:47:35AM +0100, Philip Hazel wrote:
> > 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.
>
> I already have an item on my "bugs and infelicities" list to look at
> LDAP quoting, so the clear details you've given are very timely. It
> certainly looks as though I'm going to have to end up with two different
> quoting functions.


I think there are three separate cases:

1. a value inserted into an LDAP URL search filter

      ldap:///dc=example,dc=com???(uid=${quote:$1})


=> ${quote:fred*smith} --> fred\2asmith --> fred%5C2asmith

2. a value inserted into an LDAP URL basedn

      ldap:///cn=${quote:$1},dc=example,dc=com?.....


=> ${quote:fred,smith} --> fred\,smith --> fred%5C,smith

3. a value inserted into a USER= dn

      USER=cn=${quote:$1},dc=example,dc=com PASS=$2 ldap:///...


=> ${quote:fred,smith} --> fred\,smith

IMO, case 1 should be the default for 'quote_ldap'. From what I have read,
it is considered Bad Form to hard-code rules which construct DNs from
attributes as in cases 2 and 3. If you want to construct a DN, you are
supposed to _search_ for an entry which matches your attribute criteria.
That doesn't stop people bypassing that rule though :-)

So I think quote_ldap_dn should be a separate function. I can think of some
tricks by which you can avoid having a third function; in particular, the
USER= parameter could perform URL-dequoting of its value before passing it
to the LDAP server. So quote_ldap_dn would DN-quote and URL-quote as in case
2 above, then USER= would remove the URL-quoting.

Another idea is to embed the USER= parameter in the URL itself, using the
'bindname' extension in RFC2255. However it's more work to parse this out,
and there isn't a standard 'bindpassword' extension defined as far as I
know, so it's not really any cleaner.

Now, case 3 has a problem if $1 contains embedded spaces. This could be
another argument for quote_ldap_dn performing URL quoting and USER=
performing dequoting.

#### If quote_ldap_dn does URL escaping ####

     USER=cn=${quote_ldap_dn:$1},%20dc=example,%20dc=com
     # I think that's safe


#### If quote_ldap_dn does _not_ do URL escaping ####

     USER=cn=${quote_ldap_dn:$1},dc=example,dc=com
     # Fails if $1 contains spaces


     USER="cn=${quote_ldap_dn:$1}, dc=example, dc=com"
     # I think that fails if $1 contains double-quotes or backslashes


     USER=${quote:cn=${quote_ldap_dn:$1}, dc=example, dc=com}
     # Not sure about that!


Finally, what quoting, if any, is needed for the PASS= parameter? Consider
passwords which contains spaces or double-quotes or backslashes. Is
      PASS=${quote:$2}         # exim's standard quote operator
the right thing to do?


Regards,

Brian.