[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LDAPBINDDN & LDAPBINDPW
"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