--On Thursday, April 30, 2009 8:33 PM +0000 quanah(a)zimbra.com wrote:
> Full_Name: Quanah Gibson-Mount
> Version: 2.4.16
> OS: Linux 2.6
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (75.111.29.239)
>
>
> OpenLDAP segfaulted. Dunno why:
It would look like it was in thread 1 that the segfault occurred.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Guillaume.Rousse(a)inria.fr wrote:
> Full_Name: Guillaume Rousse
> Version: 2.4.16
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (195.83.212.136)
>
>
> Current implementation of password checker doesn't allow exact errors returned
> by the external module to be returned to the client, for security reason. They
> are only available in server logs. Quoting man page:
>
> If the password is unacceptable, the server will return an error to the client,
> and ppErrStr may be used to return a human-readable textual explanation of the
> error.
>
> As it is already difficult to have strong password policies accepted by users,
> making this behaviour configurable, exactly the same way the ppolicy_use_lockout
> option allows the servers to return more information if wanted to the client,
> would be desirable.
Hmm. Perhaps the default behavior here is overly paranoid; I think it's fair
to explain to a user why their password was rejected in a PasswordModify
request. If they've already provided the correct old password, it doesn't seem
that there's any security exposure here.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Guillaume.Rousse(a)inria.fr wrote:
> Full_Name: Guillaume Rousse
> Version: 2.4.16
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (195.83.212.136)
>
>
> Current ppolicy implementation allows to administratively lock a password, by
> setting pwdAccountLockedTime attribute to '000001010000Z' value. However,
> despite this value actually being a generalized date, setting it to any other
> date in the future doesn't work as expected. Moreover, this is an operational
> attribute, which is primarily supposed to be handled by slapd itself.
>
> As a consequence, a normal pwdExpirationDate attribute, which itself would set
> a
> boolean operational attribute pwdExpired attribute to a true value, would be
> desirable.
Since the ppolicy module's behavior is dictated by the Behera draft, any
suggestions for changes in this area should probably first be raised on the
ietf-ldapext mailing list.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Guillaume.Rousse(a)inria.fr wrote:
> Full_Name: Guillaume Rousse
> Version: 2.4.16
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (195.83.212.136)
>
>
> Current implementation of ppolicy only accept an internal plugin as password
> checker. However, writing native code is more difficult for many sysadmins than
> using script languages. Moreover, it's also less safe, as any crash will
> endanger the whole slapd process. Allowing to run an external process for
> checking password would be desirable.
If you're talking about writing a checker feature that fork/execs an external
script interpreter, then I'll say up front that this is not a good idea, and
we've already been deprecating anything else that operates this way (like
back-shell). fork()/system()/spawn() whatever don't mix well with pthreads and
will most likely corrupt something.
As for isolation/crash vulnerability - this is a *password checker* - it is
already a sensitive piece of code. If you're deploying a custom module without
adequate testing or code review, you're already in trouble.
You could of course take a similar approach as back-sock - open a socket to
some other daemon that performs your checks for you. You then have to decide
how to behave when the external process isn't answering...
Ultimately, what you do inside your checker module is your own business. I see
no action needed on our part; this ITS will be closed.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Full_Name: Guillaume Rousse
Version: 2.4.16
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (195.83.212.136)
Current ppolicy implementation allows to administratively lock a password, by
setting pwdAccountLockedTime attribute to '000001010000Z' value. However,
despite this value actually being a generalized date, setting it to any other
date in the future doesn't work as expected. Moreover, this is an operational
attribute, which is primarily supposed to be handled by slapd itself.
As a consequence, a normal pwdExpirationDate attribute, which itself would set
a
boolean operational attribute pwdExpired attribute to a true value, would be
desirable.
Full_Name: Guillaume Rousse
Version: 2.4.16
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (195.83.212.136)
Current implementation of ppolicy only accept an internal plugin as password
checker. However, writing native code is more difficult for many sysadmins than
using script languages. Moreover, it's also less safe, as any crash will
endanger the whole slapd process. Allowing to run an external process for
checking password would be desirable.
Full_Name: Guillaume Rousse
Version: 2.4.16
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (195.83.212.136)
Current implementation of password checker doesn't allow exact errors returned
by the external module to be returned to the client, for security reason. They
are only available in server logs. Quoting man page:
If the password is unacceptable, the server will return an error to the client,
and ppErrStr may be used to return a human-readable textual explanation of the
error.
As it is already difficult to have strong password policies accepted by users,
making this behaviour configurable, exactly the same way the ppolicy_use_lockout
option allows the servers to return more information if wanted to the client,
would be desirable.
Full_Name: Pierangelo Masarati
Version: HEAD/re24
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (131.175.154.146)
Submitted by: ando
In fact, it exploits rwm_send_entry() to muck with entry's data as appropriate,
but passes a fake SlapReply structure, with sr_flags reset. We need to enforce
entry's release regardless of how the underlying database will take care of it.
A fix is coming.
p.