Re: LDAPBINDDN & LDAPBINDPW

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 03:56 PM 3/15/00 +0100, Lars Uffmann wrote:
>> Also, you should fstat() the opened file to avoid races.
>> You should treat the file as binary (O_BINARY) and read
>> the complete contents into struct berval.  (You can obtain
>> the size to read from the fstat()).  I suggest renaming the
>> field, defaultcred.
>
>Do you plan to use it for other bindmethods too?

Like SASL, no.  Simple passwords may contain any valid
UTF-8 character, including new lines.

>I guess the BINDPW value in a .ldaprc schould be the name of a
>file either. Also, We schould extend struct ol_attribute to
>contain a contex (GLOBAL or USER) for each attribute.

That's already been done.

>Given the considerations the API draft makes, schould the BINDPW
>stuff go into libldap or become a private feature of the ldap
>client tools?

It could be argued that all of ldap.conf(5) processing should
be independent of the session handle or, minimally, "enabled"
by the application.  That is, we could require applications
to set some flag to enable ldap.conf processing.  Applications
could then, provide appropriate command line/configuration flags
to allow user control.

At least the use of BINDPW is under user control (the user must
create the file after all).

>What benefits could I get from SASL, given the above situation?

Secure authentication and, if desired, privacy and integrity
protection.   In fact, we should disallow simple bind if TLS
is not in place.   [See my recent post about implementing
such restrictions as configurable options].