regexp problem in ldap.el?

regexp problem in ldap.el?

[Martin J. Reed]

Hi,

I have had problems with ldap.el. It seems that the version shipped
(and latest CVS) matches erroneous lines in the grabbed output from
ldapsearch when SASL authentication is used. The problem may also
occur in other situations (I think it is a genuine bug). I have had to
apply the following diff (to ldap-1.11.2.10.el grabbed from CVS):

--------------------------->8-------------------------------------
diff -u ldap-1.11.2.10.el ldap-1.11.2.10-reed.el 
--- ldap-1.11.2.10.el   2006-06-01 17:05:40.000000000 +0100
+++ ldap-1.11.2.10-reed.el      2006-06-01 17:04:41.000000000 +0100
@@ -154,7 +154,7 @@
   :type '(string :tag "`ldapsearch' Program")
   :group 'ldap)
 
-(defcustom ldap-ldapsearch-args '("-LL" "-tt" "-x")
+(defcustom ldap-ldapsearch-args '("-LL" "-tt")
   "*A list of additional arguments to pass to `ldapsearch'."
   :type '(repeat :tag "`ldapsearch' Arguments"
                 (string :tag "Argument"))
@@ -555,7 +555,7 @@
          (setq arglist (nconc arglist (list (format "-z%s" sizelimit)))))
       (eval `(call-process ldap-ldapsearch-prog
                           nil
-                          `(,buf nil)
+                          buf
                           nil
                           ,@arglist
                           ,@ldap-ldapsearch-args
@@ -580,7 +580,7 @@
                                               (end-of-line)
                                               (point))))
          (forward-line 1)
-         (while (looking-at "^\\(\\w*\\)\\(;\\w*\\)?[=:\t ]+\\(<[\t ]*file://\\)?\\(.*\\)$")
+         (while (looking-at "^\\(\\w*\\)\\(;\\w*\\)?[=:\t ]+\\(<[\t ]*file://\\)\\(.*\\)$")
            (setq name (match-string 1)
                  value (match-string 4))
             ;; Need to handle file:///D:/... as generated by OpenLDAP
--------------------------->8-------------------------------------
The main problem I have is the last change in the diff. The "?" is
removed as with it there is a match on "one or none" instances of the
"file://". This seems to mean that it grabs any available line not
just those with a "file://" in it. Then the defun tries to load files
that match the erroneous lines (and fails).

The change of ldap-ldapsearch-args is probably not important (although
do we want users to use the insecure unencrypted form by default?),
also I do not understand why the change from `(,buf nil) to buf is
required (probably my elisp ignorance).

Example output of ldapsearch that causes a problem (OpenLdap 2.2.28)
with cleaned content. The error occurs on the second line where the
(looking-at regexp...) matches true and the defun tries to load a file
"/home/myhome/username: myusername". 
-------------------------->8----------------------------------------
SASL/DIGEST-MD5 authentication started
SASL username: myusername
SASL SSF: 128
SASL installing layers
version: 1

dn: CN=xxxx,OU=xxxxxx,DC=xxxxx,DC=xx,DC=xx
objectClass:< file:///tmp/ldapsearch-objectClass-8bcsA7
objectClass:< file:///tmp/ldapsearch-objectClass-wlxT99
objectClass:< file:///tmp/ldapsearch-objectClass-GPNlJc
objectClass:< file:///tmp/ldapsearch-objectClass-G4DOif
cn:< file:///tmp/ldapsearch-cn-u79hSh
sn:< file:///tmp/ldapsearch-sn-YjeMrk
title:< file:///tmp/ldapsearch-title-qHNg1m
givenName:< file:///tmp/ldapsearch-givenName-8ATLAp
initials:< file:///tmp/ldapsearch-initials-83xhas
distinguishedName:< file:///tmp/ldapsearch-distinguishedName-uiXNJu
-------------------------->8---------------------------------------

Also there is a problem with ldapsearch from latest OpenLDAP in that
it can wrap long lines. Not sure if there is a possible fix in emacs
but maybe a warning could be added (I use a wrapper script to get rid
of the "bad line wraps").

Otherwise thanks for the updates it works much better than ldap.el
shipped with 21.4.

Regards,
 
Martin
--
Dr. M.J. Reed                               Room:          1NW.5.3G
Dept. Electronic Systems Engineering         Tel:+44 (0)1206 872479
University of Essex, Colchester CO4 3SQ, UK  FAX:+44 (0)1206 872900
Email mjreed (non Essex users should add @essex.ac.uk)
Web: http://esewww.essex.ac.uk/~mjreed

Re: regexp problem in ldap.el?

[Hallvard B Furuseth]

Martin J. Reed writes:
> diff -u ldap-1.11.2.10.el ldap-1.11.2.10-reed.el 
> --- ldap-1.11.2.10.el   2006-06-01 17:05:40.000000000 +0100
> +++ ldap-1.11.2.10-reed.el      2006-06-01 17:04:41.000000000 +0100
> @@ -154,7 +154,7 @@
>    :type '(string :tag "`ldapsearch' Program")
>    :group 'ldap)
>  
> -(defcustom ldap-ldapsearch-args '("-LL" "-tt" "-x")
> +(defcustom ldap-ldapsearch-args '("-LL" "-tt")
>    "*A list of additional arguments to pass to `ldapsearch'."

That one needs to be more complex.

With OpenLDAP ldapsearch, removing "-x" turns on SASL Bind (if it is
compiled in), and with SASL turned on you lose support for anonymous
connections.  For simple search operations, I think anonymous
connections are far more common than SASL-authenticated connections.
For that matter, plenty of server installations have not been set up
to support SASL, even when the implementation does support it.

I think -x is an OpenLDAPism though.  Solaris ldapsearch does not
understand -x, at least not on the SunOS 5.8 I just tried.  It does have
an '-M CRAM-MD5' option, which seems rather outdated:  When I tried -M
DIGEST-MD5 it reverted to anonymous Simple Bind.  And it talks about
RFC-1558 search filters, which is two LDAP RFC revisions out of date.

> The change of ldap-ldapsearch-args is probably not important (although
> do we want users to use the insecure unencrypted form by default?),

Most web pages, mail and news are unencrypted.  Why not LDAP data?

To authenticate with passwords, one should of course use encrypted
connections or authentication methods.  For this, TLS/SSL (-ZZ
argument or -H ldaps:// URLs in OpenLDAP ldapsearch) seems more
commonly supported on the server side than SASL.

Also note that SASL by itself does not provide security.  SASL is a
framework for authentication mechanisms that _may_ among other things
provide secure login and/or a security layer for the rest of the
session.  E.g. the DIGEST-MD5 SASL mechanism does, while the PLAIN
mechanism does not.  Don't know about the GSSAPI mechanism (Kerberos).

> Also there is a problem with ldapsearch from latest OpenLDAP in that
> it can wrap long lines.

OpenLDAP ldapsearch has done that for years.  It outputs LDIF format
(RFC 2849).  It supports line wrapping for the same reason base64 does:
It's a textual format, and long text lines can be problematic in some
applications.  LDIF line wrapping consists of LF or CRLF followed by one
space.  (If there is more than one space, only the first should be
removed when unwrapping.)  Only wrapped lines can start with a space.

-- 
Regards,
Hallvard