(ITS#5202) ldapsearch -E pr segfault
by kurt＠OpenLDAP.org
Full_Name: Kurt Zeilenga
Version: 2.3.38
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.141.229.206)
Here's a stack trace; the command was:
% ldapsearch -x -E pr=2/noprompt -b "o=test2,o=test" -s one "cn=*" cn
.
.
(gdb) where
#0 0x005303d4 in _int_free () from /lib/tls/libc.so.6
#1 0x0053172b in free () from /lib/tls/libc.so.6
#2 0x004201e3 in ber_memfree_x (p=0x805405d, ctx=0x0) at memory.c:149
#3 0x001d85e8 in ldap_control_free (c=0xbfe3ecd0) at controls.c:260
#4 0x001d8669 in ldap_controls_free (controls=0x9c801c8) at controls.c:285
#5 0x0804f703 in tool_server_controls (ld=0x9c76550, extra_c=0xbfe3ece0,
count=-1) at common.c:1250
#6 0x0804b910 in main (argc=14, argv=0xbfe40e44) at ldapsearch.c:794
It's done the bind ok by this stage but never gets as far as sending the search
request.
16 years, 1 month
Re: (ITS#5195) ssf not available during sasl bind
by hyc＠symas.com
russell-openldap(a)stuart.id.au wrote:
> In one sense you are correct: the userPassword read
> by slap_auxprop_lookup will never be revealed. And
> so yes, the ssf for the results of that search would
> be infinity.
>
> But what I want to check is the weakest link in the
> chain. I can't imagine any instance when that isn't
> what you would want to check, so that is what the
> ssf should reflect. By definition, the
> slap_auxprop_lookup can never be the weakest link.
> The weakest link in this case when sasl sent the
> password to slapd. Really, what I want to say is if
> the password was sent in the clear, whether it be by
> sasl or simple auth, then the link must be encrypted.
>
> The patch makes the information required to do that
> test available.
Using ACLs to enforce this requirement is the wrong approach though. You
should just use the "security" directive instead. With your approach you're
missing the fact that SASL may not have sent any password at all to slapd
(e.g., when using DIGEST-MD5 or an OTP mechanism). As such, you're imposing a
constraint that makes no sense.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
16 years, 1 month
Re: ITS#5199
by david＠schmitt.edv-bus.at
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 24 October 2007, you wrote:
> The stack backtrace you provide is useless, as it refers to the main
> thread. Please run "thread apply all bt full".
Hmpf. Thanks for your answer, I will try to get a better trace upon the next
hang.
Regards, David
- --
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHIEgZ/Pp1N6Uzh0URAjTPAJ4oiB8IlYjeDKxIGDKHDFCtQEKr2QCgnECE
x5GwRPbtZ4Cl5bMy0NlOsTc=
=nnG/
-----END PGP SIGNATURE-----
16 years, 1 month
Re: (ITS#5195) ssf not available during sasl bind
by russell-openldap＠stuart.id.au
In one sense you are correct: the userPassword read
by slap_auxprop_lookup will never be revealed. And
so yes, the ssf for the results of that search would
be infinity.
But what I want to check is the weakest link in the
chain. I can't imagine any instance when that isn't
what you would want to check, so that is what the
ssf should reflect. By definition, the
slap_auxprop_lookup can never be the weakest link.
The weakest link in this case when sasl sent the
password to slapd. Really, what I want to say is if
the password was sent in the clear, whether it be by
sasl or simple auth, then the link must be encrypted.
The patch makes the information required to do that
test available.
16 years, 1 month
RE: (ITS#5201) pcache has an incorrect LDAP_DEBUG _NONE debug statement
by mhardin＠symas.com
> From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
> Sent: Wednesday, October 24, 2007 11:43 AM
[...]
> >
> > On line 1267 of servers/slapd/overlays/pcache.c there is a debug
> > statement, "Entering QC, querystr = %s\n", which is clearly a routine
> > debug statement specific to pcache. The channel used is LDAP_DEBUG_NONE,
> > and this makes for very chatty output when a loglevel of 'none' is
> > specified in slapd.conf and the pcache overlay is in use. The log
> channel
> > should be changed to 'pcache_debug' instead.
>
> This is already fixed in REL_ENG_2_3, REL_ENG_2_4, and HEAD.
I just saw that- reject if you care to.
> --Quanah
-Matt
Matthew Hardin
Symas Corporation- The LDAP Guys
http://www.symas.com
16 years, 1 month
Re: (ITS#5201) pcache has an incorrect LDAP_DEBUG _NONE debug statement
by quanah＠zimbra.com
--On Wednesday, October 24, 2007 5:27 PM +0000 mhardin(a)symas.com wrote:
> Full_Name: Matthew Hardin
> Version: 2.3.38
> OS: All
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (74.38.114.43)
>
>
> On line 1267 of servers/slapd/overlays/pcache.c there is a debug
> statement, "Entering QC, querystr = %s\n", which is clearly a routine
> debug statement specific to pcache. The channel used is LDAP_DEBUG_NONE,
> and this makes for very chatty output when a loglevel of 'none' is
> specified in slapd.conf and the pcache overlay is in use. The log channel
> should be changed to 'pcache' instead.
This is already fixed in REL_ENG_2_3, REL_ENG_2_4, and HEAD.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
16 years, 1 month
(ITS#5201) pcache has an incorrect LDAP_DEBUG _NONE debug statement
by mhardin＠symas.com
Full_Name: Matthew Hardin
Version: 2.3.38
OS: All
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (74.38.114.43)
On line 1267 of servers/slapd/overlays/pcache.c there is a debug statement,
"Entering QC, querystr = %s\n", which is clearly a routine debug statement
specific to pcache. The channel used is LDAP_DEBUG_NONE, and this makes for very
chatty output when a loglevel of 'none' is specified in slapd.conf and the
pcache overlay is in use. The log channel should be changed to 'pcache' instead.
16 years, 1 month
ITS#5199
by ando＠sys-net.it
The stack backtrace you provide is useless, as it refers to the main
thread. Please run "thread apply all bt full".
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
16 years, 1 month
(ITS#5200) Wrong maxderefdepth doc or default
by h.b.furuseth＠usit.uio.no
Full_Name: Hallvard B Furuseth
Version: HEAD, RE23, RE24
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
slapd.conf(5) and slapd-config(5) say MaxDerefDepth defaults to 1, but
include/ldap_defaults.h says #define SLAPD_DEFAULT_MAXDEREFDEPTH 15.
16 years, 1 month
(ITS#5199) slapd sometimes hangs with back-sql
by david＠schmitt.edv-bus.at
Full_Name: David Schmitt
Version: 2.3.38
OS: Debian etch
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (193.170.138.34)
Hi!
I have OSX clients authenticating via slapd against my postgres database. Once
every fortnight slapd stops responding to requests. I got this backtrace out of
it:
0x00002b28372e20f5 in pthread_join () from /lib/libpthread.so.0
(gdb) bt full
#0 0x00002b28372e20f5 in pthread_join () from /lib/libpthread.so.0
No symbol table info available.
#1 0x00000000004230d2 in slapd_daemon ()
at /root/tmp/openldap2.3-2.3.38/servers/slapd/daemon.c:2579
listener_tid = 1082132832
rc = 0
#2 0x000000000041665f in main (argc=5, argv=0x7fff748e4288)
at /root/tmp/openldap2.3-2.3.38/servers/slapd/main.c:859
save_errno = <value optimized out>
fp = (FILE *) 0x6a4f70
i = <value optimized out>
no_detach = 0
rc = 1
urls = <value optimized out>
username = 0x605030 "gidNumber"
groupname = 0x605010 "\226{P7(+"
sandbox = 0x0
syslogUser = 160
configfile = <value optimized out>
configdir = <value optimized out>
serverName = <value optimized out>
scp = <value optimized out>
scp_entry = <value optimized out>
debug_unknowns = (char **) 0x0
syslog_unknowns = (char **) 0x0
l = <value optimized out>
slapd_pid_file_unlink = 1
slapd_args_file_unlink = 1
__PRETTY_FUNCTION__ = "main"
(gdb)
When testing with ldapsearch, the client connects, but doesn't receive any
data.
This is running on a 2.6.21-2-vserver-amd64 kernel, within a vserver container.
16 years, 1 month
