- openldap-bugs - openldap.org

Re: (ITS#5812) New option to disable SASL host canonicalization
by hyc＠symas.com 20 Nov '08

20 Nov '08

geert(a)boskant.nl wrote: > Full_Name: Geert Jansen > Version: 2.4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/geert-jansen-081115.patch > Submission from: (NULL) (12.230.186.195) > > > This is a resubmission of my earlier patch in [1]. I'm asking for this patch to > be included into OpenLDAP. > > The patch adds an LDAP option called LDAP_OPT_X_SASL_NOCANON to disable host > name canonicalization using reverse DNS for the host name that is passed into > SASL. Instead, it passes verbatim the host name part from the LDAP URI and lets > SASL do the canonicalization. The option is disabled by default. > Since some time MIT Kerberos has support for server-side canonicalization which > is an alternative for the DNS based scheme. By default it uses both, but with an > option "rdns = no", reverse DNS can be disabled. > > The use case for this is environments that do not have reverse DNS set up > correctly. Especially in Windows Active Directory environments this is very > common. Administrators are afraid to enable scavenging for their zones, and > therefore any server IP change will leave a stale PTR record in place. This > breaks reverse DNS based canonicalization if the IP adress is reassigned. > > The behaviour enabled by this patch should remain optional and cannot become the > default. It breaks the use case when multiple LDAP servers are load balanced > using a CNAME record. In reviewing this patch, I see some technical issues to resolve: 1) You seem to be making the ldap_set_option "arg" parameter optional; there appears to be no justification for this (significant) behavioral change. 2) If you're dealing with a KDC that supports this feature, then it would make the most sense for this to be a site-wide option. As such, it should be possible for the setting to become the default, and an ldap.conf keyword should exist to control that setting. 3) Your addition of the option to the command line tools is boolean; if the command line option is present the option will be turned on, otherwise it will be turned off. This requires too much knowledge on the part of the user running the tool, to decide whether they need the option or not. Again, it should allow a system-wide setting, and the command-line option should be tri-state: on / off / default. Users should not be required to learn about this option before using the commandline tools, the sysadmin should set it site-wide when the KDC is known to support it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5820) segfault with slapacl
by ghenry＠OpenLDAP.org 20 Nov '08

20 Nov '08

----- ando(a)sys-net.it wrote: > Gavin Henry wrote: > >>> Anyone else seeing this? > >>> > >> Working here. > > > > I'm on 4.7.25 with patches, 32-bit. You? > > Same here. On a different 32-bit machine it passes on Head. Weird. Will check it out. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by rra＠stanford.edu 20 Nov '08

20 Nov '08

Howard Chu <hyc(a)symas.com> writes: > Leaving aside your followup which clarified this clause: the obvious > point is that a Kerberos client needs to have trusted *local* data to > protect against this attack. All Kerberos clients have trusted local data. It's required by the Kerberos protocol; the server gives you a TGT that you can only decrypt using your trusted local data. So I'm not sure what you're getting at here. The problem with DNS canonicalization is that it allows you to attack clients even if those clients have trusted local data to establish mutual authentication with the KDC. > Delegating administration authority still implies that you trust whoever > you delegated it to. Again, if you can't trust everyone then your > administrative procedures are broken and your framework has already been > compromised. Yes, it implies that you trust them to take the actions that you delegated to them. However, it *doesn't* imply that you trust them universally. You can delegate control of some principals and not others. That's a meaningful operation that is entirely valid within the Kerberos protocol trust model. Control of one principal in a realm should not imply an ability to spoof authentications to other principals in the same realm. Kerberos as a protocol can and is designed to be robust against attackers who have control over principals within your local realm provided that a client and a server agree on principal naming for a service. Kerberos clients are specifically cautioned in the Kerberos protocol specification against using insecure DNS to establish that agreement naming. Section 1.3 of RFC 4120, particularly the two paragraphs starting with: Implementations of Kerberos and protocols based on Kerberos MUST NOT use insecure DNS queries to canonicalize the hostname components of the service principal names (i.e., they MUST NOT use insecure DNS queries to map one name to another to determine the host part of the principal name with which one is to communicate). and the security considerations section of RFC 4752, namely: When constructing the input_name_string, the client SHOULD NOT canonicalize the server's fully qualified domain name using an insecure or untrusted directory service. are relevant here. The delegated administrative model that I describe is in widespread use; in fact, I don't know of any of my colleagues who *don't* do something similar to that. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5820) segfault with slapacl
by ando＠sys-net.it 20 Nov '08

20 Nov '08

Gavin Henry wrote: >>> Anyone else seeing this? >>> >> Working here. > > I'm on 4.7.25 with patches, 32-bit. You? Same here. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5820) segfault with slapacl
by ghenry＠OpenLDAP.org 20 Nov '08

20 Nov '08

> > > > Anyone else seeing this? > > > > Working here. I'm on 4.7.25 with patches, 32-bit. You? -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5820) segfault with slapacl
by ando＠sys-net.it 20 Nov '08

20 Nov '08

ghenry(a)OpenLDAP.org wrote: > ----- "Pierangelo Masarati" <ando(a)sys-net.it> wrote: > >> ghenry(a)OpenLDAP.org wrote: >> >>> I've just hit this: >>> >>> /usr/local/sbin/slapacl -f /usr/local/etc/openldap/slapd.conf -b >>> "dc=suretecsystems,dc=com" -U ghenry "userPassword/read:" >>> authcDN: "uid=ghenry,cn=auth" >>> read access to userPassword=: DENIED >>> Segmentation fault >> Fixed in HEAD, please test. Thanks, p. > > Thanks. I'm trying to build HEAD, but it's failing test43: > >>>>>> ./scripts/test043-delta-syncrepl failed (exit 1) > make[2]: *** [bdb-mod] Error 1 > make[2]: Leaving directory `/anything/src/openldap/ldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/anything/src/openldap/ldap/tests' > make: *** [test] Error 2 > > [ghenry@suretec testrun]$ diff -urN server1.out server2.out > --- server1.out 2008-11-20 20:49:08.000000000 +0000 > +++ server2.out 2008-11-20 20:49:08.000000000 +0000 > @@ -151,7 +151,7 @@ > contextCSN: 20081120204853.248356Z#000000#000#000000 > entryDN: dc=example,dc=com > subschemaSubentry: cn=Subschema > -auditContext: cn=log > +hasSubordinates: TRUE > > dn: cn=Gern Jensen,ou=Information Technology Division,ou=People,dc=example,dc= > com > > Anyone else seeing this? > Working here. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5820) segfault with slapacl
by ghenry＠OpenLDAP.org 20 Nov '08

20 Nov '08

----- "Pierangelo Masarati" <ando(a)sys-net.it> wrote: > ghenry(a)OpenLDAP.org wrote: > > > I've just hit this: > > > > /usr/local/sbin/slapacl -f /usr/local/etc/openldap/slapd.conf -b > > "dc=suretecsystems,dc=com" -U ghenry "userPassword/read:" > > authcDN: "uid=ghenry,cn=auth" > > read access to userPassword=: DENIED > > Segmentation fault > > Fixed in HEAD, please test. Thanks, p. Thanks. I'm trying to build HEAD, but it's failing test43: >>>>> ./scripts/test043-delta-syncrepl failed (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/anything/src/openldap/ldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/anything/src/openldap/ldap/tests' make: *** [test] Error 2 [ghenry@suretec testrun]$ diff -urN server1.out server2.out --- server1.out 2008-11-20 20:49:08.000000000 +0000 +++ server2.out 2008-11-20 20:49:08.000000000 +0000 @@ -151,7 +151,7 @@ contextCSN: 20081120204853.248356Z#000000#000#000000 entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema -auditContext: cn=log +hasSubordinates: TRUE dn: cn=Gern Jensen,ou=Information Technology Division,ou=People,dc=example,dc= com Anyone else seeing this? -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by hyc＠symas.com 20 Nov '08

20 Nov '08

Russ Allbery wrote: > My impression is that the broader Kerberos community is increasingly > leaning towards not doing DNS canonicalization. That Kerberos libraries > have been canonicalizing hostnames using DNS for quite some time is > certainly true, but it's considered an unfortunate bug that needs to be > supported for backward compatibility but that is clearly not the right way > to do things. This is the reason why Kerberos implementations are > increasingly adding options to disable DNS canonicalization. > > (1) is a vulnerability that Kerberos can protect against if you use it > properly. It's called the Zanarotti attack, and the way that you defend > against it is by obtaining a service ticket for a principal in a local > keytab after initial authentication and verifying that the service ticket > matches. This uses your shared secret with the KDC to verify that you're > talking to the right KDC. Leaving aside your followup which clarified this clause: the obvious point is that a Kerberos client needs to have trusted *local* data to protect against this attack. Delegating the trust to the KDC obviously doesn't solve this problem. (Not to mention that again, a KDC is by definition a trusted 3rd party. If you can't trust it, then the entire Kerberos framework is compromised.) > Your analysis of (2) assumes that every ldap principal in your KDC is > created by someone you trust not to spoof any other ldap principal in your > KDC. Yes, again, that is implicit in the fact that the KDC is a trusted 3rd party. > That's a high bar to meet and many sites are not going to meet that > bar, nor want to given a competing desire for distributed administration. Delegating administration authority still implies that you trust whoever you delegated it to. Again, if you can't trust everyone then your administrative procedures are broken and your framework has already been compromised. > For example, Stanford allows students to run Kerberized services on their > personal computers if they wish, and therefore allows them to download > keytabs (and hence create ldap principals) for those computers. If they > can use DNS hijacking to return a CNAME for an LDAP server pointing to > their computer instead, they can obtain a legitimate keytab for the ldap > principal for that computer, and can successfully trick a client that > trusts DNS canonicalization. Trust within a realm is all-or-nothing. And of course, Kerberos trust is transitive... But the right way to handle regions under different administrative control is to place them in separate realms. For your example of students creating their own principals, independently from the centrally administered realm, you should be using a separate realm (and setup a cross-realm trust if that's appropriate.) That at least gives you consistent accountability, and you can uniformly limit the privileges granted to tickets from non-default realms. > Another, possibly more obvious case where (2) doesn't hold is in the > presence of cross-realm trust. If I can use DNS spoofing to return a > CNAME of ldap.stanford.edu to dorm-machine.mit.edu, and stanford.edu and > ATHENA.MIT.EDU have cross-realm trust, I can perform the same attack. So > you not only have to trust everyone who can create ldap principals in your > local realm, but everyone who can create ldap principals in any realm with > which you have cross-realm trust. Yes, and again, that is basic to the definition of Kerberos. If you don't actually trust everyone, then you should not be adding them into your KDC, because their presence in the KDC is a declaration of trust. Garbage-in-garbage-out applies here. > There are a lot of nasty things that you can do with DNS spoofing, and > this almost certainly isn't the most likely attack, but it is a potential > vulnerability that's been widely discussed within the Kerberos community, > including transition plans for how to get away from always doing > canonicalization. You can, for example, see part of the opinion of the > MIT developers in the comments around the relevant segment of code: > > if (maybe_use_reverse_dns(context, DEFAULT_RDNS_LOOKUP)) { > /* > * Do a reverse resolution to get the full name, just in > * case there's some funny business going on. If there > * isn't an in-addr record, give up. > */ > /* XXX: This is *so* bogus. There are several cases where > this won't get us the canonical name of the host, but > this is what we've trained people to expect. We'll > probably fix it at some point, but let's try to > preserve the current behavior and only shake things up > once when it comes time to fix this lossage. */ > > This is the reason why there's an rdns option in krb5.conf to disable this > code. There has been other discussion of it on krbdev and > kerberos(a)mit.edu in the past. > > I would agree that there's no way that you can change the default; too > much stuff would break. That's also why the Kerberos libraries continue > to do this by default. But I think the original bug reporter isn't > unreasonable for wanting a way to disable canonicalization if they know > that their code and environment will handle that appropriately. You've already proven that the option being discussed here is *not appropriate* because a non-local KDC cannot be trusted. So once again, solve the real problem. What's been proposed here is not a solution. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by rra＠stanford.edu 20 Nov '08

20 Nov '08

rra(a)stanford.edu writes: > (1) is a vulnerability that Kerberos can protect against if you use it > properly. It's called the Zanarotti attack, and the way that you defend > against it is by obtaining a service ticket for a principal in a local > keytab after initial authentication and verifying that the service > ticket matches. I'm sorry -- this is wrong. I overthought this. The scenario discussed here is not the Zanarotti attack. The Zanarotti attack involves spoofing the KDC so that you don't have to know the correct key for a principal; you instead use a key that you know and fool the system into talking to a KDC that uses the same key. It's an attack on login or a screen saver to allow someone to use a bogus password to authenticate. The protection against the scenario (1) listed here is integral into the Kerberos protocol. The Kerberos authentication process involves requesting a TGT from the KDC that's encrypted in your private key and then decrypting the return with your private key. You cannot spoof Kerberos initial authentication from a keytab or a correct password by using DNS to redirect the authentication to a bogus KDC because the bogus KDC won't know your correct private key and hence won't be able to return a TGT that you can decrypt. Similarly, you can't successfully redirect a TGS_REQ to a bogus KDC because that KDC doesn't have the private key and can't complete the protocol exchange. This is why kinit doesn't bother to protect against the Zanarotti attack; there's no need, since kinit doesn't provide increased local privileges and the Zanarotti attack is an attack only on the local system, not against a network service. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by rra＠stanford.edu 20 Nov '08

20 Nov '08

hyc(a)symas.com writes: > In the meantime, the arguments about secure DNS are pure red herrings: > 1. if your DNS has been hijacked, it's most likely that you'll be > directed to a rogue KDC first, so the question of which service you're > talking to is moot. > 2. there's nothing to gain from directing you to a rogue service, since if > you managed to contact the legitimate KDC, you're going to have a service > ticket that can only be decoded by the legitimate service principal. > On the other hand, if the rogue service is actually a valid principal in > your trusted KDC's database, then you clearly have an administrative problem > in your KDC. > > This patch attempts to provide a band-aid without actually solving the > real problem. It merely masks the problem temporarily, until it gets > even worse. My impression is that the broader Kerberos community is increasingly leaning towards not doing DNS canonicalization. That Kerberos libraries have been canonicalizing hostnames using DNS for quite some time is certainly true, but it's considered an unfortunate bug that needs to be supported for backward compatibility but that is clearly not the right way to do things. This is the reason why Kerberos implementations are increasingly adding options to disable DNS canonicalization. (1) is a vulnerability that Kerberos can protect against if you use it properly. It's called the Zanarotti attack, and the way that you defend against it is by obtaining a service ticket for a principal in a local keytab after initial authentication and verifying that the service ticket matches. This uses your shared secret with the KDC to verify that you're talking to the right KDC. Software such as PAM modules that do Kerberos authentications do this check as a matter of course. Once you've done that, further communication with the KDC is done using the session keys in your TGT, and a hijacked KDC won't be able to complete the protocol exchange because it can't decrypt the TGT. kinit and similar programs currently don't do this check by default, but there's no reason why they couldn't if an appropriate keytab is available. Your analysis of (2) assumes that every ldap principal in your KDC is created by someone you trust not to spoof any other ldap principal in your KDC. That's a high bar to meet and many sites are not going to meet that bar, nor want to given a competing desire for distributed administration. For example, Stanford allows students to run Kerberized services on their personal computers if they wish, and therefore allows them to download keytabs (and hence create ldap principals) for those computers. If they can use DNS hijacking to return a CNAME for an LDAP server pointing to their computer instead, they can obtain a legitimate keytab for the ldap principal for that computer, and can successfully trick a client that trusts DNS canonicalization. Another, possibly more obvious case where (2) doesn't hold is in the presence of cross-realm trust. If I can use DNS spoofing to return a CNAME of ldap.stanford.edu to dorm-machine.mit.edu, and stanford.edu and ATHENA.MIT.EDU have cross-realm trust, I can perform the same attack. So you not only have to trust everyone who can create ldap principals in your local realm, but everyone who can create ldap principals in any realm with which you have cross-realm trust. There are a lot of nasty things that you can do with DNS spoofing, and this almost certainly isn't the most likely attack, but it is a potential vulnerability that's been widely discussed within the Kerberos community, including transition plans for how to get away from always doing canonicalization. You can, for example, see part of the opinion of the MIT developers in the comments around the relevant segment of code: if (maybe_use_reverse_dns(context, DEFAULT_RDNS_LOOKUP)) { /* * Do a reverse resolution to get the full name, just in * case there's some funny business going on. If there * isn't an in-addr record, give up. */ /* XXX: This is *so* bogus. There are several cases where this won't get us the canonical name of the host, but this is what we've trained people to expect. We'll probably fix it at some point, but let's try to preserve the current behavior and only shake things up once when it comes time to fix this lossage. */ This is the reason why there's an rdns option in krb5.conf to disable this code. There has been other discussion of it on krbdev and kerberos(a)mit.edu in the past. I would agree that there's no way that you can change the default; too much stuff would break. That's also why the Kerberos libraries continue to do this by default. But I think the original bug reporter isn't unreasonable for wanting a way to disable canonicalization if they know that their code and environment will handle that appropriately. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5820) segfault with slapacl
by ando＠sys-net.it 20 Nov '08

20 Nov '08

ghenry(a)OpenLDAP.org wrote: > I've just hit this: > > /usr/local/sbin/slapacl -f /usr/local/etc/openldap/slapd.conf -b > "dc=suretecsystems,dc=com" -U ghenry "userPassword/read:" > authcDN: "uid=ghenry,cn=auth" > read access to userPassword=: DENIED > Segmentation fault Fixed in HEAD, please test. Thanks, 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: ITS#5821 Small mistake in man page
by ando＠sys-net.it 20 Nov '08

20 Nov '08

Fixed in HEAD; please check. Thanks, 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: ITS#5822 slapd goes into sleeping mode
by ando＠sys-net.it 20 Nov '08

20 Nov '08

There exists no OpenLDAP 2.1 b102. There exists a 2.1 branch, which was obsoleted few years ago. Even if there existed one, you don't provide enough info that could help debugging your issue. Please see <http://www.openldap.org/faq/data/cache/56.html> for details about how to report an issue. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5822) slapd goes into sleeping mode
by egarciab＠alcatel-lucent.com 20 Nov '08

20 Nov '08

Full_Name: Eduardo Garcia Version: slapd 2.1 b102 OS: solaris 5.9 URL: ftp://ftp.openldap.org/incoming/traza_mala Submission from: (NULL) (194.113.59.80) Hello, We are using a customized version of the slapd v2.1 b102. The problem that we are seeing in the last days is that the slapd process goes into a sleeping mode, and none ldap request is answered. This problems seems to happend in an intervals of 72 hours more or less. The process slapd is alive, but it seems to be stuck. Last time this problem arised, I run a truss command to get more clues about it. Above these lines, you can find the ooutput of truss and also a snoop of the port 389 in the slapd machine. Could you please look into this problem? Any further info you need , please tell me. Thanks a lot in advance Eduardo PS: we have implemented a local script to verify if the slapd process is up and answering and we could see that in the moment when this problem happens, the slapd did not answer to this local ldap request either. It kept sleeping and running This was the output of the truss command: /1: lwp_wait(2, 0xFFBFFCC4) (sleeping...) /4: lwp_park(0x00000000, 0) (sleeping...) /5: lwp_park(0x00000000, 0) (sleeping...) /7: lwp_park(0x00000000, 0) (sleeping...) /11: lwp_park(0x00000000, 0) (sleeping...) /8: lwp_park(0x00000000, 0) (sleeping...) /12: lwp_park(0x00000000, 0) (sleeping...) /13: lwp_park(0x00000000, 0) (sleeping...) /10: read(15, 0x002E6476, 2064) (sleeping...) /18: lwp_park(0x00000000, 0) (sleeping...) /17: lwp_park(0x00000000, 0) (sleeping...) /16: lwp_park(0x00000000, 0) (sleeping...) /3: lwp_park(0x00000000, 0) (sleeping...) /15: lwp_park(0x00000000, 0) (sleeping...) /9: lwp_park(0x00000000, 0) (sleeping...) /2: poll(0xFE3FD418, 3, -1) (sleeping...) /6: lwp_park(0x00000000, 0) (sleeping...) /14: lwp_park(0x00000000, 0) (sleeping...) I also get a snoop trace in the slapd machine to see which was the messages received and sent from our machine ---> traza_mala file at ftp://ftp.openldap.org/incoming/

1 0

(ITS#5821) Small mistake in man page
by kkalev＠gmail.com 20 Nov '08

20 Nov '08

Full_Name: Kostas Kalevras Version: 2.4.12 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (147.102.247.100) In the manpage for slapd.conf (slapd.conf.5) in the limits directive description the value for the size.unchecked pattern should be disabled and not disable according to limits.c

1 0

Re: (ITS#5793) RFE for flexible logging at 256/stats level
by ando＠sys-net.it 20 Nov '08

20 Nov '08

michael(a)stroeder.com wrote: > ando(a)sys-net.it wrote: >> Wouldn't it make sense to entirely give up syslog'ging and use >> slapo-accesslog instead? > > Hmm, I think this change would be too radical. I still see some value in > text messages going to syslog. Configuration issues are sometimes more > obvious if you see the syslog messages of LDAP-enabled components and > the LDAP server one after the other in the same log. I meant "give up" by not looking at logs for Gavin's purposes, not to eradicate them from the code. Modifying "stats" logging would not probably be a big issue, if we define a specific mask: one bit for each operation, and one bit for success/failure. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5793) RFE for flexible logging at 256/stats level
by michael＠stroeder.com 20 Nov '08

20 Nov '08

ando(a)sys-net.it wrote: > Wouldn't it make sense to entirely give up syslog'ging and use > slapo-accesslog instead? Hmm, I think this change would be too radical. I still see some value in text messages going to syslog. Configuration issues are sometimes more obvious if you see the syslog messages of LDAP-enabled components and the LDAP server one after the other in the same log. Ciao, Michael.

1 0

(ITS#5820) segfault with slapacl
by ghenry＠OpenLDAP.org 20 Nov '08

20 Nov '08

Full_Name: Gavin Henry Version: 2.4.12 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Hi All, I've just hit this: /usr/local/sbin/slapacl -f /usr/local/etc/openldap/slapd.conf -b "dc=suretecsystems,dc=com" -U ghenry "userPassword/read:" authcDN: "uid=ghenry,cn=auth" read access to userPassword=: DENIED Segmentation fault gdb: Starting program: /usr/local/sbin/slapacl -f /usr/local/etc/openldap/slapd.conf -b "dc=suretecsystems,dc=com" -U ghenry "userPassword/read:" (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1208350960 (LWP 10744)] authcDN: "uid=ghenry,cn=auth" read access to userPassword=: DENIED Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208350960 (LWP 10744)] 0x005f70c7 in free () from /lib/libc.so.6 (gdb) bt #0 0x005f70c7 in free () from /lib/libc.so.6 #1 0x00158c0a in ber_memfree_x (p=0x0, ctx=0x0) at memory.c:152 #2 0x08089ee8 in ch_free () #3 0x080d4d3c in slap_tool_destroy () #4 0x080d71a1 in slapacl () #5 0x080564d2 in main () (gdb) q I'm just compiling up HEAD now to test with the latest code and will get back to you. Gavin.

1 0

Re: (ITS#5819) On add, slapd does not add distinguished values if naming attribute already present
by ando＠sys-net.it 19 Nov '08

19 Nov '08

Fixed in HEAD; please test. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5819) On add, slapd does not add distinguished values if naming attribute already present
by ando＠sys-net.it 19 Nov '08

19 Nov '08

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 To trigger, try # works fine dn: cn=Foo,dc=example,dc=com objectClass: device # error dn: cn=Bar,dc=example,dc=com objectClass: device cn: Foo I'd expect both to succeed, and a "cn" of "Foo" or "Bar" to be automatically added by slapd according to RFC4511 (since "cn" is multi-valued). p.

1 0

Re: (ITS#5793) RFE for flexible logging at 256/stats level
by ghenry＠OpenLDAP.org 19 Nov '08

19 Nov '08

----- "Pierangelo Masarati" <ando(a)sys-net.it> wrote: > ghenry(a)OpenLDAP.org wrote: > > > Just a quick note to say it would be nice to be able to break out > loglevel 256 > > i.e. Log just writes. The same as accesslog config. > > Are you thinking of something like a read/write/auth flag, plus > possibly > a success/failure flag, or a per-operation granularity? Probably the later. It's more to not lot searches, but writes, as 256 can really fill up your logfile. > Wouldn't it make sense to entirely give up syslog'ging and use > slapo-accesslog instead? For some users, yes. But having the phyiscal log is appealing too. Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5817) ldapadd crashes with '-' in input
by ando＠sys-net.it 19 Nov '08

19 Nov '08

Jan Safranek wrote: > Pierangelo Masarati wrote: >> I've applied a fix to HEAD code, please test. > > Thanks for a quick fix! Now it prints "ldap_add: Bad parameter to an > ldap routine (-9)", which is a bit better than the assert before. Yes. I modified ldap_add_ext(3) to further validate input parameters instead of crashing. ldapadd(1) needs work in order to intercept the issue earlier and complain as appropriate. I was more concerned by libldap because it might be used in more critical applications than ldapadd(1) itself. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5817) ldapadd crashes with '-' in input
by jsafrane＠redhat.com 19 Nov '08

19 Nov '08

Pierangelo Masarati wrote: > I've applied a fix to HEAD code, please test. Thanks for a quick fix! Now it prints "ldap_add: Bad parameter to an ldap routine (-9)", which is a bit better than the assert before. Jan

1 0

Re: (ITS#5764) addpartial patch
by ando＠sys-net.it 19 Nov '08

19 Nov '08

hyc(a)symas.com wrote: > dhawes(a)vt.edu wrote: >> The patch referenced previously can be discarded. This patch contains >> all changes against 2.4.12. > > I suspect HEAD and 2.4.12 are identical here so it's no big deal this time, > but remember for future reference, > > http://www.openldap.org/devel/contributing.html > > all contributions must be relative to HEAD. I also note that you should not diff generated files, like Makefile. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5793) RFE for flexible logging at 256/stats level
by ando＠sys-net.it 19 Nov '08

19 Nov '08

ghenry(a)OpenLDAP.org wrote: > Just a quick note to say it would be nice to be able to break out loglevel 256 > i.e. Log just writes. The same as accesslog config. Are you thinking of something like a read/write/auth flag, plus possibly a success/failure flag, or a per-operation granularity? Wouldn't it make sense to entirely give up syslog'ging and use slapo-accesslog instead? 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5816) back-ldap stops searching if send_search_entry() returns harmless errors (like insufficientAccess)
by ando＠sys-net.it 18 Nov '08

18 Nov '08

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > To trigger: define acls that block one entry, and the search will stop at that > entry. A fix is coming... Fixed in HEAD (and in re24, apparently). I confirm back-meta does not appear to suffer from this issue. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5805) Problem when modifying access control
by rein＠OpenLDAP.org 18 Nov '08

18 Nov '08

emmanuel.duru(a)atosorigin.com skrev: > OK, my mistake, here follows a completely detailed description. > * I perform the ldap modifications with this LDIF file: [cut] > * I try to bind : > ldapsearch.exe -x -D cn=manager,c=fr -w secret -s base -b "" objectclass=* + > I get: > ldap_bind: Invalid credentials (49) > * I stop slapd [cut] > * I restart slapd > * I try to bind : > ldapsearch.exe -x -D cn=manager,c=fr -w secret -s base -b "" objectclass=* + > It works fine. Dynamic updates to the frontend ACL doesn't take place until slapd is restarted, ref ITS#5572. A fix is included in CVS HEAD and RE24, and will be included in the upcoming 2.4.13 release. Rein

1 0

Re: (ITS#5805) Problem when modifying access control
by ando＠sys-net.it 18 Nov '08

18 Nov '08

Emmanuel Duru wrote: > OK, my mistake, here follows a completely detailed description. I confirm HEAD and re24 behave as expected. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by hyc＠symas.com 18 Nov '08

18 Nov '08

ali.pouya(a)free.fr wrote: > So I checked out the HEAD last night. > The good news is that the problem is fixed now and every thing seems OK (six new > modifications have been made to syncprov.c since Nov 2, one of which being made > by Quanah and related to this issue). Not sure what you're looking at, but the CVS log clearly shows that this bug was fixed in revision 1.251 on November 2. http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/syncprov.c?… The updates after 1.252 are merely copying from HEAD to the RE24 branch. You said you pulled from HEAD on November 3, and still saw the problem. Either your checkout was wrong, or your configuration was wrong, because the fix was definitely present in HEAD by then. > So the issue can be closed :-) > Thanks again > Best Regards > Ali -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by hyc＠symas.com 18 Nov '08

18 Nov '08

Ali Pouya wrote: > Hi Howard, > Sorry for being back again but I think that a residue of the problem of > whole tree scanning persists : > The improvement is that it only happens once if the mirrors are not > synchronized (the later statups are OK). That's the normal behavior for the syncrepl protocol. Read the Admin Guide or RFC4533 for details. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5818) Limits chapter for Admin Guide
by ghenry＠OpenLDAP.org 18 Nov '08

18 Nov '08

----- "andrew findlay" <andrew.findlay(a)skills-1st.co.uk> wrote: > Full_Name: Andrew Findlay > Version: HEAD > OS: Linux > URL: > ftp://ftp.openldap.org/incoming/andrew-findlay-limits.sdf-20081118 > Submission from: (NULL) (88.97.25.132) > > > The Admin Guide says very little about size limits and time limits. > I have supplied a chapter to remedy the lack: I suggest putting it in > after the > Access Control chapter: > > ftp://ftp.openldap.org/incoming/andrew-findlay-limits.sdf-20081118 > > Please check the section on limits for paged results extra carefully. > I found the definition in slapd.conf(5) a little ambiguous. > > I have also provided patches to the master sdf file and to the two > config > directive > chapters: > > ftp://ftp.openldap.org/incoming/andrew-findlay-limits-patch-20081118 > > Andrew Thanks Andrew, I'll review and get back to when possible. Gavin. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5818) Limits chapter for Admin Guide
by andrew.findlay＠skills-1st.co.uk 18 Nov '08

18 Nov '08

Full_Name: Andrew Findlay Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/andrew-findlay-limits.sdf-20081118 Submission from: (NULL) (88.97.25.132) The Admin Guide says very little about size limits and time limits. I have supplied a chapter to remedy the lack: I suggest putting it in after the Access Control chapter: ftp://ftp.openldap.org/incoming/andrew-findlay-limits.sdf-20081118 Please check the section on limits for paged results extra carefully. I found the definition in slapd.conf(5) a little ambiguous. I have also provided patches to the master sdf file and to the two config directive chapters: ftp://ftp.openldap.org/incoming/andrew-findlay-limits-patch-20081118 Andrew

1 0

Re: (ITS#5817) ldapadd crashes with '-' in input
by ando＠sys-net.it 18 Nov '08

18 Nov '08

jsafrane(a)redhat.com wrote: > Full_Name: Jan Safranek > Version: 2.4.12 > OS: Linux (Fedora 9) > URL: > Submission from: (NULL) (89.102.11.105) > > > ldapadd crashes with assertion 'ldapadd: encode.c:392: ber_put_string: Assertion > `str != ((void *)0)' failed.' on following input: > > dn: nisMapName=netgroup.byhost,dc=my-domain,dc=com > nismapname: netgroup.byhost > objectClass: top > objectClass: nisMap > - > > The reason is probably at ldapmodify.c:445, where the lines containing dash are > skipped, apparently for modify operations: > > if ( line[0] == '-' && !line[1] ) { > BER_BVZERO( btype+i ); > freeval[i] = 0; > continue; > } > > ldap_add_ext() seems not to like these empty spaces. I think the fix belongs to ldap_add_ext(), as other applications may well call it with invalid parameters. I've applied a fix to HEAD code, please test. The fix is Checking in libraries/libldap/add.c; /repo/OpenLDAP/pkg/ldap/libraries/libldap/add.c,v <-- add.c new revision: 1.32; previous revision: 1.31 It hould apply straightforwardly to the release you're using. Thanks, 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5817) ldapadd crashes with '-' in input
by jsafrane＠redhat.com 18 Nov '08

18 Nov '08

Full_Name: Jan Safranek Version: 2.4.12 OS: Linux (Fedora 9) URL: Submission from: (NULL) (89.102.11.105) ldapadd crashes with assertion 'ldapadd: encode.c:392: ber_put_string: Assertion `str != ((void *)0)' failed.' on following input: dn: nisMapName=netgroup.byhost,dc=my-domain,dc=com nismapname: netgroup.byhost objectClass: top objectClass: nisMap - The reason is probably at ldapmodify.c:445, where the lines containing dash are skipped, apparently for modify operations: if ( line[0] == '-' && !line[1] ) { BER_BVZERO( btype+i ); freeval[i] = 0; continue; } ldap_add_ext() seems not to like these empty spaces. Full backtrace: (gdb) bt full #0 0x0000003ea4832215 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x0000003ea4833d83 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x0000003ea482b039 in __assert_fail () from /lib64/libc.so.6 No symbol table info available. #3 0x0000000000440e0e in ber_put_string (ber=0x1573390, str=0x0, tag=18446744073709551615) at encode.c:392 __PRETTY_FUNCTION__ = "ber_put_string" #4 0x0000000000441f5e in ber_printf (ber=0x1573390, fmt=0x44b34e "s[V]N}") at encode.c:809 ap = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = 0x7fffeaf5ed80, reg_save_area = 0x7fffeaf5ecc0}} s = 0x0 ss = (char **) 0x0 bv = (struct berval *) 0x7fffeaf5ecf0 bvp = (struct berval **) 0x157b718 rc = 0 i = 2 len = 0 __PRETTY_FUNCTION__ = "ber_printf" #5 0x0000000000414edd in ldap_add_ext (ld=0x15731d0, dn=0x157c714 "nisMapName=netgroup.byhost,dc=my-domain,dc=com", attrs=0x157b6e8, sctrls=0x0, cctrls=0x0, msgidp=0x7fffeaf5ee6c) at add.c:154 ber = (BerElement *) 0x1573390 i = 2 rc = 30 id = 2 __PRETTY_FUNCTION__ = "ldap_add_ext" #6 0x0000000000406c07 in domodify (dn=0x157c714 "nisMapName=netgroup.byhost,dc=my-domain,dc=com", pmods=0x157b6e8, pctrls=0x0, newentry=1) at ldapmodify.c:1094 msgid = 0 rc = -352981360 i = 3 j = 4474435 k = 0 notascii = 976894522 op = 0 bvp = (struct berval *) 0xa0 #7 0x00000000004063e9 in process_ldif_rec (rbuf=0x157c786 "", linenum=1) at ldapmodify.c:866 line = 0x0 dn = 0x157c714 "nisMapName=netgroup.byhost,dc=my-domain,dc=com" newrdn = 0x0 newsup = 0x0 rc = 0 modop = 0 expect_modop = 0 expect_sep = 0 deleteoldrdn = 1 new_entry = 1 delete_entry = 0 got_all = 0 pmods = (LDAPMod **) 0x157b6e8 lm = (LDAPMod *) 0x157b6a0 version = 0 pctrls = (LDAPControl **) 0x0 i = 5 j = 3 k = 6 lines = 5 idn = 1 nmods = 3 btype = (struct berval *) 0x157b5d0 vals = (struct berval *) 0x157b630 bvl = (struct berval **) 0x157b708 bv = {bv_len = 0, bv_val = 0x0} freeval = 0x157b690 "" mops = (unsigned char *) 0x0 #8 0x000000000040458b in main (argc=11, argv=0x7fffeaf5f178) at ldapmodify.c:341 rbuf = 0x157c710 "dn" rejbuf = 0x0 rejfp = (FILE *) 0x0 ldiffp = (struct LDIFFP *) 0x1572e50 ldifdummy = {fp = 0x0, prev = 0x0} matched_msg = 0x4473c0 "H\211l$�L\211|$�H\215-/\034!" error_msg = 0x0 rc = 0 retval = 0 len = 32767 i = 0 lineno = 1 nextline = 6 lmax = 4147 c = {{ldctl_oid = 0x7fffeaf5f020 "\214�|�����3\020", ldctl_value = {bv_len = 226974810936, bv_val = 0x3ea480ae20 "\016\001"}, ldctl_iscritical = 0 '\0'}}

1 0

RE: (ITS#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 18 Nov '08

18 Nov '08

Sorry the command to create the initial database is not slapadd -f configdb -l initialdatabase.ldif but slapadd -F configdb -l initialdatabase.ldif

1 0

RE: (ITS#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 18 Nov '08

18 Nov '08

OK, my mistake, here follows a completely detailed description. * I have a slapd.conf as follows -----------------begin slapd.conf include schema/core.schema include schema/cosine.schema include schema/inetorgperson.schema pidfile slapd.pid argsfile slapd.args access to * attrs=userPassword by self write by anonymous auth by * none access to dn=cn=manager,c=fr by self write by * none access to * by self write by users read by anonymous read by * none database bdb suffix "c=fr" rootdn "cn=manager,c=fr" cachesize 20000 checkpoint 10000 10 directory db index objectClass,entryCSN,entryUUID eq index cn,sn eq,sub -----------------end slapd.conf * I convert this slapd.conf to a configdb: slapd -f slapd.conf -F configdb * I stop slapd. * I create the initial database with the following LDIF file: -----------------begin initial database dn: c=fr objectClass: country c: fr dn: cn=manager,c=fr objectClass: person cn: manager sn: manager userPassword:: c2VjcmV0 dn: cn=user,c=fr objectClass: person cn: user sn: user userPassword:: dXNlcg== dn: cn=user2,c=fr objectClass: person cn: user2 sn: user2 userPassword:: dXNlcjI= -----------------end initial database slapadd -f configdb -l initialdatabase.ldif * I edit olcDatabase={0}config.ldif file to replace olcRootDN: cn=config by olcRootDN: cn=manager,c=fr * I start slapd slapd -d 256 -F configdb * I try to bind : ldapsearch.exe -x -D cn=manager,c=fr -w secret -s base -b "" objectclass=* + It works fine. * I perform the ldap modifications with this LDIF file: -----------------begin LDAP modifications dn: olcDatabase={-1}frontend,cn=config changetype: modify replace: olcAccess olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * no ne olcAccess: {1}to dn=cn=manager,c=fr by self write by * none olcAccess: {2}to * by self write by users read by anonymous read by * none dn: olcDatabase={0}config,cn=config changetype: modify replace: olcAccess olcAccess: {0}to * by * none -----------------end LDAP modifications ldapmodify -x -D cn=manager,c=fr -w secret -f LDAPmodifications.ldif * I try to bind : ldapsearch.exe -x -D cn=manager,c=fr -w secret -s base -b "" objectclass=* + I get: ldap_bind: Invalid credentials (49) * I stop slapd I get: filter_free: unknown filter type=19008 filter_free: unknown filter type=13304 slapd stopped. filter_free: unknown filter type=13744 filter_free: unknown filter type=1264 filter_free: unknown filter type=13744 filter_free: unknown filter type=1264 and slapd crashes. * I restart slapd * I try to bind : ldapsearch.exe -x -D cn=manager,c=fr -w secret -s base -b "" objectclass=* + It works fine.

1 0

(ITS#5816) back-ldap stops searching if send_search_entry() returns harmless errors (like insufficientAccess)
by ando＠sys-net.it 18 Nov '08

18 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando To trigger: define acls that block one entry, and the search will stop at that entry. A fix is coming... p.

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr 17 Nov '08

17 Nov '08

Hi Howard, Sorry for being back again but I think that a residue of the problem of whole tree scanning persists : The improvement is that it only happens once if the mirrors are not synchronized (the later statups are OK). I uploaded the new archive file ITS_5640_new.tar.gz to the FTP server (incoming directory). To reproduce the problem y can proceed as explained in folowwup 9. Thanks Best Regards Ali

1 0

Re: (ITS#5796) back-sql intermittently failing
by robb＠wtg.cw.com 17 Nov '08

17 Nov '08

Pierangelo Masarati wrote: > OK, this makes sense. In fact, back-sql does not seem to specifically > handle broken connections to the odbc. It appears it would need > something similar to idle-timeout as in back-ldap and back-meta. current work-around is to set "idletimeout" in openldap shorter than mysql's "wait_timeout" (default 8hrs).

1 0

Re: (ITS#5805) Problem when modifying access control
by ando＠sys-net.it 17 Nov '08

17 Nov '08

emmanuel.duru(a)atosorigin.com wrote: > I'm sorry, but I don't. > cn=manager,c=fr was already the rootdn of config database (as well as rootdn > of c=fr database) before doing the test, with no rootpw in the config > database. > My first test consisted in modifying both olcAccess and olcRootDn for all > databases (if present) without changing any value (replacing the existing > values with the same ones). Then I made another test, with olcAccess > modifications only (on both frontend and config databases), and the problem > still appears. It only appears if I modify olcAccess of both databases, and > in this order: frontend then config. Well, I simply followed what you described in your bug report (at least what I understood). Next time, please provide a full featured script that fires up slapd and performs the offending writes. I'll change "cannot reproduce" to "report obscure". 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

RE: (ITS#5805) Problem when modifying access control
by h.b.furuseth＠usit.uio.no 17 Nov '08

17 Nov '08

Please post your configuration (minus any passwords) so it's possible to test what you are doing. Makes for less guesswork too. -- Hallvard

1 0

RE: (ITS#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 17 Nov '08

17 Nov '08

I'm sorry, but I don't. cn=manager,c=fr was already the rootdn of config database (as well as rootdn of c=fr database) before doing the test, with no rootpw in the config database. My first test consisted in modifying both olcAccess and olcRootDn for all databases (if present) without changing any value (replacing the existing values with the same ones). Then I made another test, with olcAccess modifications only (on both frontend and config databases), and the problem still appears. It only appears if I modify olcAccess of both databases, and in this order: frontend then config. > > You do, since you modify the configuration using the cn=config rootdn in > order to modify itself, and set it to cn=manager,c=fr. So in the first > place you had a rootdn in cn=config, with a rootpw. And the > modification you posted did not remove the rootpw.

1 0

Re: (ITS#5805) Problem when modifying access control
by ando＠sys-net.it 17 Nov '08

17 Nov '08

emmanuel.duru(a)atosorigin.com wrote: >> Emmanuel Duru wrote: >>> I wouldn't say that it is harmless. >> I'm not saying your problem is harmless. I'm saying that having a >> rootdn of cn=config that is not within cn=config but with the rootpw is >> a violation of slapd's configuration rules (when the rootdn is not >> within the naming context, it cannot have a rootpw set). >> > > But I don't. > My rootdn is cn=manager,c=fr which is a real entry in the c=fr database > (bdb) with the password in the entry and no rootpw neither in c=fr nor in > cn=config. You do, since you modify the configuration using the cn=config rootdn in order to modify itself, and set it to cn=manager,c=fr. So in the first place you had a rootdn in cn=config, with a rootpw. And the modification you posted did not remove the rootpw. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

RE: (ITS#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 17 Nov '08

17 Nov '08

> Emmanuel Duru wrote: > > I wouldn't say that it is harmless. > > I'm not saying your problem is harmless. I'm saying that having a > rootdn of cn=config that is not within cn=config but with the rootpw is > a violation of slapd's configuration rules (when the rootdn is not > within the naming context, it cannot have a rootpw set). > But I don't. My rootdn is cn=manager,c=fr which is a real entry in the c=fr database (bdb) with the password in the entry and no rootpw neither in c=fr nor in cn=config.

1 0

Re: (ITS#5805) Problem when modifying access control
by ando＠sys-net.it 17 Nov '08

17 Nov '08

Emmanuel Duru wrote: > I wouldn't say that it is harmless. I'm not saying your problem is harmless. I'm saying that having a rootdn of cn=config that is not within cn=config but with the rootpw is a violation of slapd's configuration rules (when the rootdn is not within the naming context, it cannot have a rootpw set). > To sum up, the problem is that when I modify frontend access control and > then config access control (olcAccess attribute in both cases), I can not > bind any more (neither with rootdn nor with any other dn). > Concerning further releases, I will try later. Maybe I will wait for the > 2.4.13... Fine. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

RE: (ITS#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 17 Nov '08

17 Nov '08

I wouldn't say that it is harmless. To sum up, the problem is that when I modify frontend access control and then config access control (olcAccess attribute in both cases), I can not bind any more (neither with rootdn nor with any other dn). Concerning further releases, I will try later. Maybe I will wait for the 2.4.13... > -----Message d'origine----- > De : Pierangelo Masarati [mailto:ando@sys-net.it] > Envoyé : dimanche 16 novembre 2008 22:01 > À : emmanuel.duru(a)atosorigin.com > Cc : openldap-its(a)openldap.org > Objet : Re: (ITS#5805) Problem when modifying access control > > emmanuel.duru(a)atosorigin.com wrote: > > Full_Name: Emmanuel Duru > > Version: 2.4.11 > > OS: Windows > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (80.78.0.137) > > > > > > I have a single BDB database directory with root DN as a physical entry. > My > > access control is defined as follows in olcDatabase={-1}frontend: > > olcAccess: {0}to attrs=userPassword by self write by anonymous auth > by * no > > ne > > olcAccess: {1}to dn=cn=manager,c=fr by self write by * none > > olcAccess: {2}to * by self write by users read by anonymous read by > * none > > > > I perform a modify operation as follows: > > dn: olcDatabase={-1}frontend,cn=config > > changetype: modify > > replace: olcAccess > > olcAccess: {0}to attrs=userPassword by self write by anonymous auth > by * no > > ne > > olcAccess: {1}to dn=cn=manager,c=fr by self write by * none > > olcAccess: {2}to * by self write by users read by anonymous read by > * none > > > > dn: olcDatabase={0}config,cn=config > > changetype: modify > > replace: olcAccess > > olcAccess: {0}to * by * none > > - > > replace: olcRootDN > > olcRootDN: cn=manager,c=fr > > > > then I can not bind any more to the directory (invalid credentials). > > The log says (do notice the line dn: [1]... with non printable > characters): > > do_bind: version=3 dn="cn=manager,c=fr" method=128 > > ==> bdb_bind: dn: cn=manager,c=fr > > bdb_dn2entry("cn=manager,c=fr") > > => access_allowed: auth access to "cn=manager,c=fr" "userPassword" > requested > > => dn: [1] <some non printable characters>anager,c=fr > > => acl_get: [2] attr userPassword > > => slap_access_allowed: result not in cache (userPassword) > > => acl_mask: access to entry "cn=manager,c=fr", attr "userPassword" > requested > > => acl_mask: to value by "", (=0) > > <= check a_dn_pat: * > > <= acl_mask: [1] applying none(=0) (stop) > > <= acl_mask: [1] mask: none(=0) > > => slap_access_allowed: auth access denied by none(=0) > > => access_allowed: no more rules > > > > When I stop the directory, the log says (filter_free lines may vary): > > bdb_db_close: database "c=fr": alock_close failed > > filter_free: unknown filter type=20224 > > filter_free: unknown filter type=496 > > slapd stopped. > > filter_free: unknown filter type=29776 > > filter_free: unknown filter type=13944 > > filter_free: unknown filter type=29496 > > > > When I restart slapd, all is fine: the access control is OK and I can > bind. > > I can't confirm your report with HEAD code. I suggest you retry with > either 2.4.12 or (better) re24, which is about to be released as 2.4.13. > I note that by performing the operations you indicate, the cn=config > database (dn: olcDatabase={0}config,cn=config) ends up in an > inconsistent state, because the rootdn does not belong to its naming > context, but the rootpw is set, which should not be allowed. A check > for this does not exist, while it should. In any case, this is harmless. > > 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 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > -----------------------------------

1 0

Posible bug with alias
by Alberto Gomez 17 Nov '08

17 Nov '08

Hi, I have found a possible bug on OpenLDAP when querying an entry which is an alias. This is the query: ldapsearch -x -h localhost -L -b "msisdn=911,dc=msisdn,ou=aliases,dc=mybasedn" -s subtree -a search # # LDAPv3 # base <msisdn=911,dc=msisdn,ou=aliases,dc=mybasedn> with scope subtre e # filter: (objectclass=*) # requesting: ALL # # 111, realentries, mybasedn dn: subsId=111,ou=realentries,dc=mybasedn objectClass: top objectClass: RealEntry subsId: 111 # 911, msisdn, aliases, mybasedn dn: MSISDN=911,dc=msisdn,ou=aliases,dc=mybasedn objectClass: top objectClass: alias objectClass: MSISDN MSISDN: 911 aliasedObjectName: subsId=111,ou=realentries,dc=mybasedn CDC: 0 usageCnt: 1 # search result # numResponses: 3 # numEntries: 2 What I would expect is the alias entry to be returned (as the derefAlias=search) but instead I get the alias entry and the aliased entry. I am using OpenLDAP 2.3.43-1 on cygwin. Is this a bug? Best regards, Alberto Gómez

1 0

Re: (ITS#5814) concurrent access to connections
by ando＠sys-net.it 17 Nov '08

17 Nov '08

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> Hallvard B Furuseth wrote: >>> test036-meta-concurrency just crashed with fresh HEAD code. >>> I suppose that's the same as this ITS. >> Looks like. However, now I thought my FIXME were little more than a >> precaution. In fact, right now the only places where c_struct_state can >> be modified are protected by a mutex on connections_mutex; this should >> prevent changing the state of a connection during a connection_next() >> call. Do you see a thread waiting on >> ldap_pvt_thread_mutex_lock(&connections_mutex ); at connection.c:427 or >> connection.c:514? If that's the case, we probably need to move >> c->c_conn_state = SLAP_C_INACTIVE; inside the mutex in order to be able >> to safely assert in connection_next(). Is it worth? > > That should not be necessary. c_struct_state is supposed to be protected by > connections_mutex, while c_conn_state is supposed to be protected by > c->c_mutex. As already described in the comments at the top of the file. What seesm to happen is that c_conn_state is changed, then connections_mutex prevents from changing c_struct_state. As a consequence, connection_next() treats a connection structure based on its c_struct_state, which is now correctly protected, but then asserts on its c_conn_state, which has already been modified. So we are asserting on the state of a connection that is being modified, and is by design in a temporarily inconsistent state. Now things should be safe, though. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5814) concurrent access to connections
by hyc＠symas.com 17 Nov '08

17 Nov '08

ando(a)sys-net.it wrote: > Hallvard B Furuseth wrote: >> test036-meta-concurrency just crashed with fresh HEAD code. >> I suppose that's the same as this ITS. > > Looks like. However, now I thought my FIXME were little more than a > precaution. In fact, right now the only places where c_struct_state can > be modified are protected by a mutex on connections_mutex; this should > prevent changing the state of a connection during a connection_next() > call. Do you see a thread waiting on > ldap_pvt_thread_mutex_lock(&connections_mutex ); at connection.c:427 or > connection.c:514? If that's the case, we probably need to move > c->c_conn_state = SLAP_C_INACTIVE; inside the mutex in order to be able > to safely assert in connection_next(). Is it worth? That should not be necessary. c_struct_state is supposed to be protected by connections_mutex, while c_conn_state is supposed to be protected by c->c_mutex. As already described in the comments at the top of the file. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5814) concurrent access to connections
by h.b.furuseth＠usit.uio.no 16 Nov '08

16 Nov '08

Pierangelo Masarati writes: > Do you see a thread waiting on > ldap_pvt_thread_mutex_lock( &connections_mutex ); at connection.c:427 or > connection.c:514? Yes, thread 4: (gdb) thread apply all backtrace Thread 10 (process 8228): #0 0x00000038cf6075b5 in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000042afa2 in slapd_daemon () at daemon.c:2656 #2 0x00000000004198c4 in main (argc=8, argv=0x7fff65271058) at main.c:948 Thread 9 (process 8245): #0 0x00000038cead1f58 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000042d2bb in slapd_daemon_task (ptr=<value optimized out>) at daemon.c:2291 #2 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #3 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 8 (process 8260): #0 0x00000038ceab8947 in sched_yield () from /lib64/libc.so.6 #1 0x00002acc4bb99bd0 in meta_back_search (op=0x14f7c4b0, rs=0x42f23ca0) at search.c:1542 #2 0x0000000000432276 in fe_op_search (op=0x14f7c4b0, rs=0x42f23ca0) at search.c:366 #3 0x0000000000432a07 in do_search (op=0x14f7c4b0, rs=0x42f23ca0) at search.c:217 #4 0x0000000000430331 in connection_operation (ctx=0x42f23df0, arg_v=<value optimized out>) at connection.c:1090 #5 0x000000000043077d in connection_read_thread (ctx=0x42f23df0, argv=<value optimized out>) at connection.c:1216 #6 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #7 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #8 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 7 (process 8261): #0 0x00000038ceac9016 in poll () from /lib64/libc.so.6 #1 0x00002acc4584d142 in ldap_result (ld=0x15815910, msgid=346, all=1, timeout=<value optimized out>, result=0x437249e8) at result.c:355 #2 0x00002acc4bb9afa8 in meta_back_op_result (mc=0x15815810, op=0x1507ca40, rs=0x43724ca0, candidate=1, msgid=346, timeout=0, sendok=LDAP_BACK_SENDRESULT) at bind.c:1004 #3 0x00002acc4bb9e731 in meta_back_modrdn (op=0x1507ca40, rs=0x43724ca0) at modrdn.c:141 #4 0x000000000044874a in fe_op_modrdn (op=0x1507ca40, rs=0x43724ca0) at modrdn.c:314 #5 0x00000000004491b4 in do_modrdn (op=0x1507ca40, rs=0x43724ca0) at modrdn.c:186 #6 0x0000000000430331 in connection_operation (ctx=0x43724df0, arg_v=<value optimized out>) at connection.c:1090 #7 0x000000000043077d in connection_read_thread (ctx=0x43724df0, argv=<value optimized out>) at connection.c:1216 #8 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #9 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #10 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 6 (process 8391): #0 0x00000038ceac9016 in poll () from /lib64/libc.so.6 #1 0x00002acc4584d142 in ldap_result (ld=0x1519d440, msgid=87, all=2, timeout=<value optimized out>, result=0x41b015f0) at result.c:355 #2 0x00002acc4bb9773c in meta_back_search (op=0x41b01640, rs=0x41b017b0) at search.c:1027 #3 0x00002acc4bba07a3 in meta_back_get_candidate (op=0x151c0b70, rs=0x41b01ca0, ndn=0x41b019a0) at conn.c:891 #4 0x00002acc4bba26fa in meta_back_getconn (op=0x151c0b70, rs=0x41b01ca0, candidate=0x0, sendok=LDAP_BACK_BINDING) at conn.c:1325 #5 0x00002acc4bb9c4cb in meta_back_bind (op=0x151c0b70, rs=0x41b01ca0) at bind.c:96 #6 0x000000000044b52e in fe_op_bind (op=0x151c0b70, rs=0x41b01ca0) at bind.c:383 #7 0x000000000044bf2f in do_bind (op=0x151c0b70, rs=0x41b01ca0) at bind.c:205 #8 0x0000000000430331 in connection_operation (ctx=0x41b01df0, arg_v=<value optimized out>) at connection.c:1090 #9 0x000000000043077d in connection_read_thread (ctx=0x41b01df0, argv=<value optimized out>) at connection.c:1216 #10 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #11 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #12 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 5 (process 8392): #0 0x00000038cf60c888 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00000038cf6088a5 in _L_mutex_lock_107 () from /lib64/libpthread.so.0 #2 0x00000038cf608333 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00002acc4bdb2b57 in monitor_cache_lock (e=<value optimized out>) at cache.c:117 #4 0x00002acc4bdb1f9f in monitor_send_children (op=0x152cf4f0, rs=0x43f25ca0, e_parent=<value optimized out>, sub=1) at search.c:144 #5 0x00002acc4bdb2017 in monitor_send_children (op=0x152cf4f0, rs=0x43f25ca0, e_parent=<value optimized out>, sub=1) at search.c:123 #6 0x00002acc4bdb23a7 in monitor_back_search (op=0x152cf4f0, rs=0x43f25ca0) at search.c:245 #7 0x0000000000432276 in fe_op_search (op=0x152cf4f0, rs=0x43f25ca0) at search.c:366 #8 0x0000000000432a07 in do_search (op=0x152cf4f0, rs=0x43f25ca0) at search.c:217 #9 0x0000000000430331 in connection_operation (ctx=0x43f25df0, arg_v=<value optimized out>) at connection.c:1090 #10 0x000000000043077d in connection_read_thread (ctx=0x43f25df0, argv=<value optimized out>) at connection.c:1216 #11 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #12 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #13 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 4 (process 8393): #0 0x00000038cf60c888 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00000038cf6088a5 in _L_mutex_lock_107 () from /lib64/libpthread.so.0 #2 0x00000038cf608333 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x0000000000431775 in connection_init (s=31, listener=0x14e3b280, dnsname=0x4c39b5 "unknown", peername=0x447258a0 "IP=127.0.0.1:50895", flags=0, ssf=0, authid=0x0) at connection.c:514 #4 0x000000000042b40a in slap_listener_thread (ctx=<value optimized out>, ptr=<value optimized out>) at daemon.c:1965 #5 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #6 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #7 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 3 (process 8395): #0 0x00000038ceac9016 in poll () from /lib64/libc.so.6 #1 0x00002acc4584d142 in ldap_result (ld=0x152cda90, msgid=529, all=2, timeout=<value optimized out>, result=0x44f275f0) at result.c:355 #2 0x00002acc4bb9773c in meta_back_search (op=0x44f27640, rs=0x44f277b0) at search.c:1027 #3 0x00002acc4bba07a3 in meta_back_get_candidate (op=0x154d8a90, rs=0x44f27ca0, ndn=0x44f279a0) at conn.c:891 #4 0x00002acc4bba26fa in meta_back_getconn (op=0x154d8a90, rs=0x44f27ca0, candidate=0x0, sendok=LDAP_BACK_BINDING) at conn.c:1325 #5 0x00002acc4bb9c4cb in meta_back_bind (op=0x154d8a90, rs=0x44f27ca0) at bind.c:96 #6 0x000000000044b52e in fe_op_bind (op=0x154d8a90, rs=0x44f27ca0) at bind.c:383 #7 0x000000000044bf2f in do_bind (op=0x154d8a90, rs=0x44f27ca0) at bind.c:205 #8 0x0000000000430331 in connection_operation (ctx=0x44f27df0, arg_v=<value optimized out>) at connection.c:1090 #9 0x000000000043077d in connection_read_thread (ctx=0x44f27df0, argv=<value optimized out>) at connection.c:1216 #10 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #11 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #12 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 2 (process 8497): #0 0x00000038cf60a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002acc4584a1f8 in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:654 #2 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #3 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 1 (process 8498): #0 0x00000038cea30155 in raise () from /lib64/libc.so.6 #1 0x00000038cea31bf0 in abort () from /lib64/libc.so.6 #2 0x00000038cea295d6 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000431122 in connection_next (c=0x2acc4bfcad90, index=0x45f28a7c) at connection.c:877 #4 0x00002acc4bdb774f in monitor_subsys_conn_update (op=<value optimized out>, rs=<value optimized out>, e=0x14f10c88) at conn.c:230 #5 0x00002acc4bdb39cb in monitor_entry_update (op=0x2024, rs=0x45f29ca0, e=0x6) at entry.c:59 #6 0x00002acc4bdb1fd0 in monitor_send_children (op=0x15714210, rs=0x45f29ca0, e_parent=0x14f10c88, sub=1) at search.c:88 #7 0x00002acc4bdb2017 in monitor_send_children (op=0x15714210, rs=0x45f29ca0, e_parent=<value optimized out>, sub=1) at search.c:123 #8 0x00002acc4bdb23a7 in monitor_back_search (op=0x15714210, rs=0x45f29ca0) at search.c:245 #9 0x0000000000432276 in fe_op_search (op=0x15714210, rs=0x45f29ca0) at search.c:366 #10 0x0000000000432a07 in do_search (op=0x15714210, rs=0x45f29ca0) at search.c:217 #11 0x0000000000430331 in connection_operation (ctx=0x45f29df0, arg_v=<value optimized out>) at connection.c:1090 #12 0x000000000043077d in connection_read_thread (ctx=0x45f29df0, argv=<value optimized out>) at connection.c:1216 #13 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #14 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #15 0x00000038cead1b6d in clone () from /lib64/libc.so.6 (gdb) thread 4 (gdb) frame 3 #3 0x0000000000431775 in connection_init (s=31, listener=0x14e3b280, dnsname=0x4c39b5 "unknown", peername=0x447258a0 "IP=127.0.0.1:50895", flags=0, ssf=0, authid=0x0) at connection.c:514 514 ldap_pvt_thread_mutex_lock( &connections_mutex ); (gdb) p c $4 = (Connection *) 0x2acc4bfcad90 (gdb) p *c $5 = {c_struct_state = 1, c_conn_state = 1, c_conn_idx = 31, c_sd = 31, c_close_reason = 0x4c355a "?", c_mutex = {__data = {__lock = 1, __count = 0, __owner = 8393, __nusers = 1, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\001\000\000\000\000\000\000\000É \000\000\001", '\0' <repeats 26 times>, __align = 1}, c_sb = 0x2aaab0009680, c_starttime = 1226874133, c_activitytime = 1226874133, c_connid = 46, c_peer_domain = {bv_len = 7, bv_val = 0x14f72e90 "unknown"}, c_peer_name = {bv_len = 18, bv_val = 0x1581ecc0 "IP=127.0.0.1:50895"}, c_listener = 0x14e3b280, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x2acc4bfcaea8}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x2acc4bfcaeb8}, c_write_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\0' <repeats 39 times>, __align = 0}, c_write_cv = {__data = {__lock = 0, __futex = 2, __total_seq = 1, __wakeup_seq = 1, __woken_seq = 1, __mutex = 0x2acc4bfcada8, __nwaiters = 0, __broadcast_seq = 0}, __size = "\000\000\000\000\002\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000šüKÌ*\000\000\000\000\000\000\000\000\000", __align = 8589934592}, c_currentber = 0x0, c_sasl_bind_in_progress = 0 '\0', c_writewaiter = 0 '\0', c_is_tls = 0 '\0', c_needs_tls_accept = 0 '\0', c_sasl_layers = 0 '\0', c_sasl_done = 0 '\0', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_txn = 0, c_txn_backend = 0x0, c_txn_ops = {stqh_first = 0x0, stqh_last = 0x2acc4bfcaf60}, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x441cb0 <slap_send_ldap_result>, c_send_search_entry = 0x43f700 <slap_send_search_entry>, c_send_search_reference = 0x43f050 <slap_send_search_reference>, c_send_ldap_extended = 0x441810 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x4416c0 <slap_send_ldap_intermediate>} -- Hallvard

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs