Re: LDAPBINDDN & LDAPBINDPW

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

At 04:24 PM 3/14/00 +0100, Lars Uffmann wrote:
>And I hate it to
>maintain private patches to third party software, specially when there
>are frequent releases (as with OpenLDAP) which might fix serious bugs. 

Use CVS.  Checkout one of OPENLDAP_REL_ENG_1_2, OPENLDAP_RELEASE,
or OPENLDAP_STABLE tags.  Apply your patch.  Then 'cvs update' to
merge in updates if and when they become available.  The probability
of a merge conflict is extremely low and likely easily resolved.

>IMHO you schould allow minor improovments to be incooperated into 1.2.

Noted.

>In my patch, LDAPBINDPW's value is the name of a file containing the password.

Well, that's certainly better than exposing the password in ARGV or ENVP.
It could be argued that creation of the file is under user control.
I guess this is not much different that unencrypted private key files
for various authentication services to support daemons and the like.

I guess I wouldn't object to such a patch IF adequate protections
where taken to protect the contents of the file from unintended
access.  In particular, besides the checks you already made, you
should check the directory containing the file to ensure it's
owned by the user and not group/world writable.

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.

The argument should be marked as "user only" and should be
value handled exactly the same regardless of whether or
not it was obtained from .ldaprc or ENV.  A subroutine
might be appropriate.

Lastly, ldap.conf(5) needs to be updated.  It should be noted
that the file contains exact value of the credentials to
be passed.  No trailing "\n".  To create:
	echo -n "my password string" > .ldappasswd


>> Also, note, that we'll likely start prompting for "secrets"
>> as the default.  In a SASL world, the application shouldn't
>> handle "secrets".  It should just provide a mechanism to
>> allow the user to interact (ie: prompting or other) with the
>> underlying authentication services.
>
>My primary concern are automated tasks like cronjobs using the ldap
>command line tools, ie ldapsearch, ldapadd, ldapmodify and friends.

I assume users will want to use SASL authenticate for all clients.