openldap-bugs

openldap-bugs@openldap.org

1 participants
21000 discussions

Re: (ITS#5733) tainted connection
by richton＠nbcs.rutgers.edu 30 Jan '11

30 Jan '11

On Sat, 29 Jan 2011, Howard Chu wrote: > Are people still running into this? Seems like not. Time to close this > issue? I haven't seen it in a while. Closing seems reasonable.

1 0

Re: (ITS#5733) tainted connection
by hyc＠symas.com 29 Jan '11

29 Jan '11

richton(a)nbcs.rutgers.edu wrote: > I saw this three times in testing of HEAD. One backtrace and -d -1: > > https://www.nbcs.rutgers.edu/~richton/test039-bt-200906200640.txt > https://www.nbcs.rutgers.edu/~richton/test039-slapdlog-200906200640.txt > > > These are under libumem with transaction logging enabled. All malloc/free > for a given block can be retrieved, in theory... Are people still running into this? Seems like not. Time to close this issue? -- -- 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#6749) Shut up "configure monitor database to enable"
by h.b.furuseth＠usit.uio.no 29 Jan '11

29 Jan '11

masarati(a)aero.polimi.it writes: >> Please don't give the "configure monitor database to enable" message >> by default. >> >> Either just remove it, or better, stop cn=config from adding a default >> olcMonitoring: TRUE attribute to olcDatabase objects. (The flag value >> can still default to True if the attribute is absent.) Then you can >> give the message if the _admin_ has explicitly asked for monitoring, >> instead of if slapd has asked for it. > > I disagree; it is not cn=config that defaults database monitoring to TRUE; > actually, it's back-bdb/back-hdb that sets its own monitoring to TRUE as > soon as back-monitor support is compiled and the specific backend > monitoring is successfully initilized. If the admin put 'olcMonitoring: TRUE' in slapd.d but did not include database monitor, that would be poor user config. I'm fine with having bdb set the internal default flag value to TRUE. My protest in that context is against slapd - be it back-bdb or back-config which is to blame - writing the default value to the cn=config LDIF even though the admin never mentioned monitoring. This means that neither the TRUE value of the internal flag nor the presence of the attribute is an indication that the admin asked for monitoring (i.e. set the flag) but forgot to add database monitor. > Maybe this warning can be demoted to LDAP_DEBUG_CONFIG instead of > LDAP_DEBUG_ANY. Yes. Maybe slapd should nag the admin more about bad config, but if so there are plenty of other things which are more important than this and should get a chance to nag the admin before this particular flag gets to do it. IIRC the only other thing which gets to do that now is BDB without DB_CONFIG - which makes sense since that's an entire non-OpenLDAP subsystem which has not been configured. But also: > I understand that one could presume that the lack of database monitor > in the configuration indicates that monitoring is not desired; this > warning, however, tries to address a typical configuration error, when > admins just forget to configure it. No, this is a broken slapd default. It should not be an admin error to not mention a feature he does not want and does not need to know about. And if slapd does nag anyone about it, it should nag admins who do mention either database monitor or the flag, not admins who do not. So slapd should be quiet if it set the flag internally and the admin does not include database monitor. Thus my suggestion to set the flag internally by default but only nag the admin if it was set in cn=config. Unless olcMonitoring:TRUE is a drain on performance or something so it really ought to be off when the data is not used anyway. An alternative (and a change in behavior from now) if you really want this warning, would be to always default monitoring to off. That'll surprise existing users, so the cn=monitor objects could contain some text 'monitoring off for this database, set olcMonitoring to enable'. Personally I don't think a warning is worth such a change in behavior, but then I don't like the warning anyway:-) -- Hallvard

1 0

Re: (ITS#6811) Patch - Mozilla NSS - disable pkcs11 fork checking for the software token
by hyc＠symas.com 29 Jan '11

29 Jan '11

richm(a)stanfordalumni.org wrote: > The NSS_STRICT_NOFORK environment variable is documented here: > https://developer.mozilla.org/en/NSS_reference/NSS_environment_variables > > Note that if a user really wants the strict pkcs11 behavior, the user > can set the variable to "1" or some other non-empty value (other than > "DISABLED"). > > If you think further documentation is required, I would be happy to > update the Admin Guide, FAQ-o-matic, man pages, etc. That looks fine. Most of our docs were written specifically to OpenSSL but we've added one or two references to GnuTLS since then. I would start by adding to the FAQ-o-Matic: http://www.openldap.org/faq/data/cache/196.html I guess we could update this to mention the availability of GnuTLS and MozNSS support and perhaps a discussion of their pros and cons. (Though in all honesty I cannot think of any pros for using GnuTLS. I would use PolarSSL instead but that's not what the Debian folks asked for...) Hm, this entire FAQ page is far out of date. If you want to add some MozNSS info here go ahead, I'll take a pass at the rest of the page later. -- -- 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#6811) Patch - Mozilla NSS - disable pkcs11 fork checking for the software token
by richm＠stanfordalumni.org 29 Jan '11

29 Jan '11

The NSS_STRICT_NOFORK environment variable is documented here: https://developer.mozilla.org/en/NSS_reference/NSS_environment_variables Note that if a user really wants the strict pkcs11 behavior, the user can set the variable to "1" or some other non-empty value (other than "DISABLED"). If you think further documentation is required, I would be happy to update the Admin Guide, FAQ-o-matic, man pages, etc.

1 0

Re: (ITS#6684) Patch for autogroup overlay
by hyc＠symas.com 29 Jan '11

29 Jan '11

moenoel(a)informatik.uni-bremen.de wrote: >> 1) it should simply be comparing the AttributeDescription pointers >> 2) since the "memberof" attribute is actually configurable in the memberof >> overlay, there's no guarantee that this is the correct attribute to be looking >> for. It should also be configurable in your patch. >> >> You're using strcasecmp, but your inputs are already normalized values. You >> should just use ber_bvcmp. >> > > Since I am also interested in this, I took some time to make a new > patch. I took Norberts original patch, applied it to a current checkout > from HEAD and tried to fix the issues mentioned by Howard. My initial > tests are looking good. > > My C skills are rather mediocre, though, so I hope I didn't slaughter > the thing :-) > > http://www.informatik.uni-bremen.de/~moenoel/ldap/christian-manal-autogroup… This patch looks pretty good. There are only one or two minor issues with it, which I will clean up. (E.g., config actions require no mutexes; slapd is always single-threaded when processing config changes.) -- -- 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#6806) Invalid ldapadd crashes openldap with ndb backend
by hyc＠symas.com 29 Jan '11

29 Jan '11

anderson(a)vailsys.com wrote: > Full_Name: Nathanael Anderson > Version: 2.4.19 > OS: RHEL 6 (Linux) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.63.156.11) > > > #00_die.ldif > > dn: cn=die,ou=groups,dc=domain,dc=com > objectclass: groupofnames > cn: Operations > description: People in Operations > > ldapadd -x -D "cn=admin,dc=domain,dc=com" -W -f 00_die.ldif > > This will crash the openldap server every time with a Bus error message > > conn=0 op=1 ADD dn="cn=die,ou=groups,dc=domain,dc=com" > Entry (cn=die,ou=groups,dc=domain,dc=com): object class 'groupOfNames' requires > attribute 'member' > conn=0 op=1 RESULT tag=105 err=65 text=object class 'groupOfNames' requires > attribute 'member' > Bus error (core dumped) > As always, when you get a core dump, post the gdb backtrace of the dump. Use the most recent release version, and make sure you use a non-optimized debug build with all debug symbols intact. All of these instructions are written on the page where you submit new Issues. -- -- 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#6811) Patch - Mozilla NSS - disable pkcs11 fork checking for the software token
by hyc＠symas.com 29 Jan '11

29 Jan '11

richm(a)stanfordalumni.org wrote: > On Sat, Jan 29, 2011 at 3:26 AM,<hyc(a)symas.com> wrote: >> rmeggins(a)redhat.com wrote: >>> Full_Name: Rich Megginson >>> Version: 2.4.23 (current CVS HEAD) >>> OS: RHEL6 >>> URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-moznss-disable-nofo= > rk-20110127.patch >>> Submission from: (NULL) (76.113.111.209) >>> >>> >>> There are some applications that acquire a crypto context in the parent = > process >>> and expect that crypto context to work after a fork(). =A0This does not = > work >>> with MozNSS using strict PKCS11 compliance mode. =A0We set the environme= > nt >>> variable NSS_STRICT_NOFORK=3DDISABLED in tlsm_init() to tell the softwar= > e >>> encryption module/token to allow crypto contexts to persist across a for= > k(). >>> However, if you are using some other module or encryption device that su= > pports >>> and expects full PKCS11 semantics, the only recourse is to modify the >>> application to use atfork() handlers to save the crypto context in the p= > arent >>> and restore (and SECMOD_RestartModules) the context in the child. >> >> Sounds like this is a followon to #6802. Is this really critical at this >> point? We really need to close the window on RE24 patches so we can actua= > lly >> cut a release. But if ITS#6802 is actually incomplete, I guess we should = > roll >> this in. > > Yes, it is a followon to 6802 - as it turns out, the patch to 6802 was > incomplete. We have discovered some important applications such as > sshd/su/others that open an LDAP* connection in the parent process, > fork(), and attempt to use the same LDAP* handle in the child. Some > of the other Fedora/Red Hat developers and I had a discussion with one > of the MozNSS developers about this issue, as ldap is not the only > affected area. It was decided that the best thing is to simply > disable the fork() checking in the MozNSS software token pkcs11 crypto > module. This will give us parity with openssl with respect to fork() > behavior. It is a critical issue for Fedora/Red Hat. I understand > that this is coming in late in the game and you may not be able to get > this into RE24. If not, Fedora/Red Hat will carry a patch for this. Is this env var and atfork() workaround already documented in the NSS documentation? Just wondering if we need to say anything about it in our Admin Guide, FAQ-o-Matic, or manpages. -- -- 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#6811) Patch - Mozilla NSS - disable pkcs11 fork checking for the software token
by richm＠stanfordalumni.org 29 Jan '11

29 Jan '11

On Sat, Jan 29, 2011 at 3:26 AM, <hyc(a)symas.com> wrote: > rmeggins(a)redhat.com wrote: >> Full_Name: Rich Megginson >> Version: 2.4.23 (current CVS HEAD) >> OS: RHEL6 >> URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-moznss-disable-nofo= rk-20110127.patch >> Submission from: (NULL) (76.113.111.209) >> >> >> There are some applications that acquire a crypto context in the parent = process >> and expect that crypto context to work after a fork(). =A0This does not = work >> with MozNSS using strict PKCS11 compliance mode. =A0We set the environme= nt >> variable NSS_STRICT_NOFORK=3DDISABLED in tlsm_init() to tell the softwar= e >> encryption module/token to allow crypto contexts to persist across a for= k(). >> However, if you are using some other module or encryption device that su= pports >> and expects full PKCS11 semantics, the only recourse is to modify the >> application to use atfork() handlers to save the crypto context in the p= arent >> and restore (and SECMOD_RestartModules) the context in the child. > > Sounds like this is a followon to #6802. Is this really critical at this > point? We really need to close the window on RE24 patches so we can actua= lly > cut a release. But if ITS#6802 is actually incomplete, I guess we should = roll > this in. Yes, it is a followon to 6802 - as it turns out, the patch to 6802 was incomplete. We have discovered some important applications such as sshd/su/others that open an LDAP* connection in the parent process, fork(), and attempt to use the same LDAP* handle in the child. Some of the other Fedora/Red Hat developers and I had a discussion with one of the MozNSS developers about this issue, as ldap is not the only affected area. It was decided that the best thing is to simply disable the fork() checking in the MozNSS software token pkcs11 crypto module. This will give us parity with openssl with respect to fork() behavior. It is a critical issue for Fedora/Red Hat. I understand that this is coming in late in the game and you may not be able to get this into RE24. If not, Fedora/Red Hat will carry a patch for this. > >> These patch files are derived from OpenLDAP Software. All of the >> modifications to OpenLDAP Software represented in the following >> patch(es) were developed by Red Hat. Red Hat has not assigned rights >> and/or interest in this work to any party. I, Rich Megginson am >> authorized by Red Hat, my employer, to release this work under the >> following terms. >> >> Red Hat hereby place the following modifications to OpenLDAP Software >> (and only these modifications) into the public domain. Hence, these >> modifications may be freely used and/or redistributed for any purpose >> with or without attribution and/or other notice. >> > > > -- > =A0 -- Howard Chu > =A0 CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 http://www.symas.com > =A0 Director, Highland Sun =A0 =A0 http://highlandsun.com/hyc/ > =A0 Chief Architect, OpenLDAP =A0http://www.openldap.org/project/ > > >

1 0

Re: (ITS#6811) Patch - Mozilla NSS - disable pkcs11 fork checking for the software token
by hyc＠symas.com 29 Jan '11

29 Jan '11

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.23 (current CVS HEAD) > OS: RHEL6 > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-moznss-disable-nofork-20110… > Submission from: (NULL) (76.113.111.209) > > > There are some applications that acquire a crypto context in the parent process > and expect that crypto context to work after a fork(). This does not work > with MozNSS using strict PKCS11 compliance mode. We set the environment > variable NSS_STRICT_NOFORK=DISABLED in tlsm_init() to tell the software > encryption module/token to allow crypto contexts to persist across a fork(). > However, if you are using some other module or encryption device that supports > and expects full PKCS11 semantics, the only recourse is to modify the > application to use atfork() handlers to save the crypto context in the parent > and restore (and SECMOD_RestartModules) the context in the child. Sounds like this is a followon to #6802. Is this really critical at this point? We really need to close the window on RE24 patches so we can actually cut a release. But if ITS#6802 is actually incomplete, I guess we should roll this in. > These patch files are derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Red Hat. Red Hat has not assigned rights > and/or interest in this work to any party. I, Rich Megginson am > authorized by Red Hat, my employer, to release this work under the > following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose > with or without attribution and/or other notice. > -- -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs