Re: LDAPBINDDN & LDAPBINDPW

[Lars Uffmann <lars.uffmann@mediaways.net>]

"Kurt D. Zeilenga" wrote:
> 
> 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.

This is probably a good Idea, I already did it this morning. Besides the
BINDPW stuff I maintain a backport of the 2.0 local bind code, to be able
to bind slapd to a specific local interface. Also, I do not want to direct
development into a direction not supported by the OpenLDAP project, that's
why I posted the BINDPW stuff.

> >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.

aggreed.

> 
> 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?

> 
> 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.

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.

> 
> 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
> 

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

> >> 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.

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

-- 
Lars Uffmann, <lars.uffmann@mediaways.net>, fon: +49 5241 80 40330