--On Friday, May 01, 2009 11:13 AM +0000 damariris(a)gmail.com wrote:
> Full_Name: Damaris
> Version: 2.2.20
> OS: ubuntu
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (83.38.79.241)
Usage questions should be sent to openldap-software(a)openldap.org. I see no
bug here.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Aaron Richton wrote:
> On Sat, 2 May 2009, Howard Chu wrote:
>
>> Fixed in HEAD. You should probably sync up with cache.c too; the tests Quanah
>> and I have been running seem to like this better.
>
> 2.4.16 + synced back-bdb from head. NULL strncmp:
There's no strncmp in this trace. This is a different symptom than before.
>
> t@14 (l@14) terminated by signal SEGV (no mapping at the fault address)
> Current function is avl_insert
> 125 cmp = fcmp( data, p->avl_data )> 0;
> (dbx) where
> current thread: t@14
> =>[1] avl_insert(root = 0x12c9e52c0, data = 0x12cd3e0f0, fcmp = 0x1001a1e90 =&`slapd`cache.c`bdb_rdn_cmp(const void *v_e1, const void *v_e2), fdup = 0x100273f00 =&avl_dup_error(void *left, void *right)), line 125 in "avl.c"
> [2] hdb_cache_find_parent(op = 0x131b07390, txn = 0x132f36090, id = 12937U, res = 0xffffffff45e7e848), line 595 in "cache.c"
> [3] hdb_cache_find_id(op = 0x131b07390, tid = 0x132f36090, id = 12937U, eip = 0xffffffff45e7e848, flag = 0, lock = 0xffffffff45e7e7f8), line 906 in "cache.c"
> [4] hdb_search(op = 0x131b07390, rs = 0xffffffff45fff998), line 706 in "search.c"
> [5] glue_sub_search(op = 0x131b07390, rs = 0xffffffff45fff998, b0 = 0xffffffff45ffeda8, on = 0x1106e0dd0), line 342 in "backglue.c"
> [6] glue_op_search(op = 0x131b07390, rs = 0xffffffff45fff998), line 465 in "backglue.c"
> [7] overlay_op_walk(op = 0x131b07390, rs = 0xffffffff45fff998, which = op_search, oi = 0x1106e1010, on = 0x1106e0dd0), line 659 in "backover.c"
> [8] over_op_func(op = 0x131b07390, rs = 0xffffffff45fff998, which = op_search), line 721 in "backover.c"
> [9] over_op_search(op = 0x131b07390, rs = 0xffffffff45fff998), line 743 in "backover.c"
> [10] fe_op_search(op = 0x131b07390, rs = 0xffffffff45fff998), line 366 in "search.c"
> [11] overlay_op_walk(op = 0x131b07390, rs = 0xffffffff45fff998, which = op_search, oi = 0x1106e16d0, on = (nil)), line 669 in "backover.c"
> [12] over_op_func(op = 0x131b07390, rs = 0xffffffff45fff998, which = op_search), line 721 in "backover.c"
> [13] over_op_search(op = 0x131b07390, rs = 0xffffffff45fff998), line 743 in "backover.c"
> [14] do_search(op = 0x131b07390, rs = 0xffffffff45fff998), line 217 in "search.c"
> [15] connection_operation(ctx = 0xffffffff45fffc20, arg_v = 0x131b07390), line 1097 in "connection.c"
> [16] connection_read_thread(ctx = 0xffffffff45fffc20, argv = 0xbf), line 1223 in "connection.c"
> [17] ldap_int_thread_pool_wrapper(xpool = 0x11062b6a0), line 663 in "tpool.c"
>
> data is null, p is null.
And the trace shows data = 0x12cd3e0f0. What are you looking at?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
On Fri, May 01, 2009 at 03:00:26PM -0700, Howard Chu wrote:
> jwm(a)horde.net wrote:
>> Full_Name: John Morrissey
>> Version: 2.4.16
>> OS: Linux
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (2001:4978:194:0:21f:5bff:fee9:da92)
>>
>> After a couple days of uptime, slapd no longer responds to incoming
>> connections (the connection would be accepted, but all LDAP operations
>> would block). All worker threads seem to be blocking on mutex acquisition
>> in bdb_cache_lru_link(). One thread was chewing lots of CPU.
>>
>> Backtrace is below. I also have a ~1.7GB core if it's deemed useful; I'll
>> keep it around for a week or two. This is with BDB 4.7.25+all three
>> patches.
>
> Interesting trace, it looks like all the active threads are waiting for
> the mutex but apparently none of them owns it. Can you please provide the
> contents of the mutex? e.g.
> thread 14
> frame 3
> print *mutex
(gdb) fra 3
#3 0xb7eec1cd in ldap_pvt_thread_mutex_lock (mutex=0x940a2cc)
at /tmp/buildd/openldap-2.4.16/libraries/libldap_r/thr_posix.c:296
296 return ERRVAL( pthread_mutex_lock( mutex ) );
(gdb) print *mutex
$1 = {__data = {__lock = 2, __count = 0, __owner = 6372, __kind = 0,
__nusers = 1, {__spins = 0, __list = {__next = 0x0}}},
__size = "\002\000\000\000\000\000\000\000###30\000\000\000\000\000\000\001\000\000\000\000\000\000", __align = 2}
LWP 6372 is the thread trying to do BDB lock promotion.
john
--
John Morrissey _o /\ ---- __o
jwm(a)horde.net _-< \_ / \ ---- < \,
www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__
hyc(a)symas.com wrote:
> jwm(a)horde.net wrote:
>> Full_Name: John Morrissey
>> Version: 2.4.16
>> OS: Linux
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (2001:4978:194:0:21f:5bff:fee9:da92)
>>
>>
>> After a couple days of uptime, slapd no longer responds to incoming connections
>> (the connection would be accepted, but all LDAP operations would block). All
>> worker threads seem to be blocking on mutex acquisition in bdb_cache_lru_link().
>> One thread was chewing lots of CPU.
>>
>> Backtrace is below. I also have a ~1.7GB core if it's deemed useful; I'll keep
>> it around for a week or two. This is with BDB 4.7.25+all three patches.
>>
> Interesting trace, it looks like all the active threads are waiting for the
> mutex but apparently none of them owns it. Can you please provide the contents
> of the mutex? e.g.
> thread 14
> frame 3
> print *mutex
Ah, I missed this before, your thread 3 is inside a BerkeleyDB lock function.
There's nothing useful in the trace for thread 3 though. It seems you may need
to recompile BerkeleyDB with debugging enabled (and with
-fno-omit-frame-pointer) to get a useful trace from this. This is looking more
like a BDB locking issue than an OpenLDAP issue. If you still have the
environment, db_stat -CA would be helpful.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
jwm(a)horde.net wrote:
> Full_Name: John Morrissey
> Version: 2.4.16
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (2001:4978:194:0:21f:5bff:fee9:da92)
>
>
> After a couple days of uptime, slapd no longer responds to incoming connections
> (the connection would be accepted, but all LDAP operations would block). All
> worker threads seem to be blocking on mutex acquisition in bdb_cache_lru_link().
> One thread was chewing lots of CPU.
>
> Backtrace is below. I also have a ~1.7GB core if it's deemed useful; I'll keep
> it around for a week or two. This is with BDB 4.7.25+all three patches.
>
Interesting trace, it looks like all the active threads are waiting for the
mutex but apparently none of them owns it. Can you please provide the contents
of the mutex? e.g.
thread 14
frame 3
print *mutex
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--On Friday, May 01, 2009 6:18 PM +0200 masarati(a)aero.polimi.it wrote:
>> --On Thursday, April 30, 2009 7:34 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)
>>
>> Cache notes for this ITS and ITS#6086:
>>
>> # Entries to cache in memory
>> cachesize 200000
>>
>> # IDL Entries to cache in memory
>> idlcachesize 200000
>>
>> # Entries to free up when cache gets full
>> cachefree 5000
>
> Are you using slapo-rwm? Can you post the configuration?
No, slapo-rwm is not in use. It's using back-hdb, slapo-valsort, dynlist,
and back-monitor.
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/dyngroup.schema
include /etc/ldap/schema/krb5-kdc.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/eduperson.schema
include /etc/ldap/schema/stanford-oids.schema
include /etc/ldap/schema/suacct.schema
include /etc/ldap/schema/superson.schema
include /etc/ldap/schema/suapplication.schema
include /etc/ldap/schema/suorg.schema
include /etc/ldap/schema/eduorg.schema
include /etc/ldap/schema/suworkgroup.schema
allow bind_v2
TLSCertificateFile /etc/ssl/certs/server.pem
TLSCertificateKeyFile /etc/ssl/private/server.key
TLSCACertificateFile /etc/ssl/certs/comodo-entrust-2012.pem
include /etc/ldap/slapd.acl.global
pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args
defaultsearchbase "dc=stanford,dc=edu"
gentlehup off
loglevel stats
threads 8
tool-threads 2
sasl-realm stanford.edu
authz-policy both
authz-regexp uid=(.*)(a)ms.stanford.edu,cn=stanford.edu,cn=gssapi,cn=auth
ldap:///cn=service-ms,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalName=$1@MS.STANFORD.EDU
authz-regexp uid=(.*)/cgi,cn=stanford.edu,cn=gssapi,cn=auth
ldap:///cn=cgi,cn=applications,dc=stanford,dc=edu??sub?krb5PrincipalName=$1/cgi@stanford.edu
authz-regexp uid=service/(.*),cn=stanford.edu,cn=gssapi,cn=auth
ldap:///cn=Service,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalName=service/$1@stanford.edu
authz-regexp uid=webauth/(.*),cn=stanford.edu,cn=gssapi,cn=auth
ldap:///cn=Webauth,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalName=webauth/$1@stanford.edu
authz-regexp uid=(.*),cn=stanford.edu,cn=gssapi,cn=auth
ldap:///uid=$1,cn=Accounts,dc=stanford,dc=edu??sub?suSeasStatus=active
reverse-lookup off
modulepath /usr/lib/ldap
moduleload back_hdb.la
moduleload back_monitor.la
moduleload valsort.la
moduleload dynlist.la
database hdb
suffix "dc=stanford,dc=edu"
rootdn "cn=manager,dc=stanford,dc=edu"
include /etc/ldap/slapd.acl.stanford
sizelimit 500
conn_max_pending_auth 2000
lastmod on
syncrepl rid=0
provider=ldap://ldap-devmaster.stanford.edu:389
bindmethod=sasl
saslmech=gssapi
realm=stanford.edu
searchbase="dc=stanford,dc=edu"
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemachecking=on
type=refreshAndPersist
retry="60 +"
syncdata=accesslog
updateref ldap://ldap-devmaster.stanford.edu
directory /var/lib/ldap
shm_key 1
dbconfig set_cachesize 1 805306368 2
dbconfig set_lg_regionmax 262144
dbconfig set_lg_bsize 2097152
dbconfig set_lg_dir /var/log/bdb
dbconfig set_lk_max_locks 6000
dbconfig set_lk_max_objects 3000
dbconfig set_lk_max_lockers 3000
dbconfig set_flags DB_LOG_AUTOREMOVE
checkpoint 1024 5
cachesize 50000
idlcachesize 50000
cachefree 1000
index_substr_any_len 3
index default eq
index cn eq,sub
index dc
index displayName eq,sub
index entryUUID
index givenName eq,sub
index homePhone eq,sub
index krb5PrincipalName
index mail eq,sub
index member pres,eq
index mobile eq,sub
index modifyTimestamp
index o
index objectClass
index pager eq,sub
index sn eq,sub,approx
... tons of indices ...
overlay valsort
valsort-attr suOrgContactStanford cn=organizations,dc=stanford,dc=edu
weighted
valsort-attr suOrgContactWorld cn=organizations,dc=stanford,dc=edu weighted
overlay dynlist
dynlist-attrset groupOfURLS memberURL member
database monitor
access to dn.subtree="cn=monitor"
by * read
sizelimit 500
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
> --On Thursday, April 30, 2009 7:34 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)
>
> Cache notes for this ITS and ITS#6086:
>
> # Entries to cache in memory
> cachesize 200000
>
> # IDL Entries to cache in memory
> idlcachesize 200000
>
> # Entries to free up when cache gets full
> cachefree 5000
Are you using slapo-rwm? Can you post the configuration?
p.
Full_Name: Damaris
Version: 2.2.20
OS: ubuntu
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (83.38.79.241)
Hi, i'm a newbie on this. I am trying to import an entry in my phpldapadmin:
dn: uid=dama, ou=rediris, ou=pfc, c=es
ObjectClass:person
ObjectClass:top
Uid: damaris
Sn: dama
Cn: dama su co
I have tried with a lot of entries, and it says always the same:
The LDAP server refused to perform the operation phpldapadmin
Can anyone help me? I have installed db Berkeley, and i have no problem to
connect and bind to my ldap server. I have no problem to connect to phpldapadmin
too, but i cannot import any entry! Is something about the schemas??
Than u in advance,
Dámaris.
--On Thursday, April 30, 2009 7:34 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)
Cache notes for this ITS and ITS#6086:
# Entries to cache in memory
cachesize 200000
# IDL Entries to cache in memory
idlcachesize 200000
# Entries to free up when cache gets full
cachefree 5000
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
--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.
Rastogi Arpit wrote:
> hi Raymond ,
>
Hi Arpit,
> This is just for my understanding . Is Password Policy response is a
> standard ? What is the requirement of this particular feature to be
> present in JLDAP? What is this feature and how it can be used ?
> We can take it in if this is a standard but if this is not a standard
> than we cannot take this in as this will make the code bulkier.
The Password Policy control is based the IETF password policy proposal
for LDAP. The following URLs provide more detail on it:
https://datatracker.ietf.org/drafts/draft-behera-ldap-password-policy/http://tools.ietf.org/draft/draft-behera-ldap-password-policy/draft-behera-…
Essentially the code I've provided allows users of JLDAP send password
policy request control messages and interpret the directory server
responses. It can be used in the following instances:
* At bind time where the directory server can indicate whether the
user's account is about to expire, has expired, or is locked.
* If the account is about to expire, how long before this occurs.
* If the account has expired, how many grace logins are left before
the account is locked out.
* At password reset time where the directory server can indicate whether
the new password meets password policy requirements including:
* Whether the password is strong enough.
* Whether the new password set is one that has already been used.
These and more are described in the URLs I have provided.
Although it is an expired draft, it is supported by OpenLDAP (in slapd
via the slapo-ppolicy overlay and is also supported by the ldapsearch
client). It is also supported by the following LDAP servers (there may
be more but these are the ones I do use):
CA/eTrust directory
OpenDS
SunONE directory
IBM Tivoli directory server
The functionality provided by the code I've written is also available in
other programming languages (Perl via Net::LDAP and in other Java LDAP
libraries).
>
> regards,
> Arpit
regards
Ray
--
Raymond B. Edah
e-mail: t2tre ^ skyblue.eu.com
web: http://www.cs.skyblue.eu.com