As I noted in our ITS#8025, this has nothing to do with upstream
OpenLDAP. It may be specific to the particular way you built OpenLDAP in
your distro, or it may be due to pam_ldap itself, but neither of these
are in the purview of the OpenLDAP Project. Certainly there is nothing
in vanilla
Try replacing pam-ldap/nss-ldap with nslcd and/or nssov and see if the
problem persists. I'd bet it doesn't. See here
https://bugs.launchpad.net/debian/+source/sudo/+bug/423252/comments/84
for reasons why you should have abandoned pam-ldap/nss-ldap years ago.
--
You received this bug
I just now discovered this was finally fixed. It only took 5 years for
someone to reinvent my patch... https://mail.gnome.org/archives
/networkmanager-list/2008-September/msg00042.html
Hopefully upstream will take this soon. Thanks for your work integrating
this much-needed feature.
--
You
Forcing use of nscd is a non-starter at many sites. Aside from cache
staleness issues, and nscd's well known instability, there's also the
issue that nscd doesn't intercept get*ent enumerations so things will
still crash depending on which nsswitch functions an app calls.
It would make sense to
This additional patch fixes the crash in bug#1013798.
** Attachment added: Addition to the patch in comment#73
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/423252/+attachment/3328846/+files/dif.txt
--
You received this bug notification because you are a member of Ubuntu
Server Team,
Oops. The attachment in comment#166 includes the patch in #73, it is not
incremental.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libnss-ldap in Ubuntu.
https://bugs.launchpad.net/bugs/423252
Title:
NSS using LDAP+SSL breaks
3 sets of LDAP client libraries? That sounds like a terrible solution.
Fwiw, I wrote a version of OpenLDAP's TLS support that could use any/all
of OpenSSL, GnuTLS, and MozillaNSS simultaneously, and never released
it, because it seemed that would be too confusing if separate apps had
different
My point being, if you want to accommodate multiple TLS libraries
simultaneously with only a single libldap, that code is still available
in the OpenLDAP git repo. The relevant changes are between
a225b02f17fe79f6680d5d31db37320981e24774..4dff3e6807fb3451405373c2b85e02ccf27b882f
--
You received
Seems like exactly the same as bug #90812. And the workaround shown
there https://bugs.launchpad.net/openldap/+bug/90812/comments/31 still
works. If this is something we should be handling upstream, please
submit an ITS. For the moment it doesn't seem like it. The discussion of
libltdl implies
For completeness' sake, another bug tracker with the same issue
https://bugs.g10code.com/gnupg/issue1181
** Bug watch added: GnuPG Bugs #1181
https://bugs.g10code.com/gnupg/issue1181
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
That's unfortunate, I didn't realize libpam-ldapd was so incomplete. You
can still use nssov for full pam support.
Your best option for an immediate fix is still the libgcrypt patch I
posted. Without that basically all Karmic and Lucid nss-ldap+SSL
installations are dead in the water. As a longer
http://www.openldap.org/devel/cvsweb.cgi/~checkout~/contrib/slapd-
modules/nssov/README?rev=1.11
It's an overlay for OpenLDAP slapd which implements all of the nss and
pam calls, replacing Arthur deJong's nslcd.
--
NSS using LDAP+SSL breaks setuid applications like su and sudo
I read all of the diffs between 1.4.1 and 1.4.4 but didn't find any
likely suspects. However, tracing the library initialization in gdb, I
found the specific problem.
Ordinarily gnutls will initialize the gcrypt library, if no app has done
so already. In the gnutls initialization, it specifically
Probably the best fix: don't call global_init when setting the thread
callbacks.
** Attachment added: potential libgcrypt fix
http://launchpadlibrarian.net/45701569/dif1.txt
--
NSS using LDAP on Karmic breaks 'su' and 'sudo'
https://bugs.launchpad.net/bugs/423252
You received this bug
Potential gnutls fix: do gcrypt initialization as long it isn't already
finished. probably a bad idea.
** Attachment added: potential gnutls fix
http://launchpadlibrarian.net/45701794/dif2.txt
--
NSS using LDAP on Karmic breaks 'su' and 'sudo'
https://bugs.launchpad.net/bugs/423252
You
Rune: just google for nscd problems, it has a long history of stability
issues. But on top of the issues caused by poor implementation, it also
has problems due to an inherently inadequate design. Some of these
issues are outlined in my LDAPCon presentation linked above. All of this
is well
I'd be happy to write a patch for the documentation. And given all of
the problems with the design (and implementation) of libnss-ldap, I'd
say any analysis will show that libnss-ldapd is still the path of lowest
risk and greatest stability. (In particular, when used with OpenLDAP
nssov.)
--
NSS
Right, given the timing for the Lucid release it's probably way too
late. I can't comment on your experience with nslcd as I have never used
its code or read it in depth. The stub library and nssov have been
pretty well tested internally in Symas; since the stub library is almost
entirely
Looking at the gcrypt code, it seems this bug should be reported against
that; this whole secmem implementation (1) requires a program to be
started as root (setuid) and (2) always drops the root priv when it has
initialized its secure memory. These behaviors would certainly interfere
with any
Great find, Andreas. So gnutls is calling gcrypt's secure memory
functions. And yet, the gnutls docs say these functions are not used by
default, and certainly OpenLDAP does not configure gnutls to use them.
Something else in the stack must be setting that behavior.
--
NSS using LDAP on Karmic
Regardless of what the root cause turns out to be, you guys really need
to switch to libnss-ldapd, which will reliably isolate the user apps
from whatever junk is going on inside libldap / gnutls / whatever. (And
if you're not using the latest version, which also handles pam_ldap,
then you need to
You can find detailed design docs at its home page
http://arthurdejong.org/nss-pam-ldapd/
You can also find my LDAPCon2009 presentation on the subject here
http://www.symas.com/ldapcon2009/papers/hyc1.shtml
--
NSS using LDAP on Karmic breaks 'su' and 'sudo'
Fixed in CVS slapd/bconfig.c 1.402
--
[karmic] slapd hangs at 100% cpu and is unkillable
https://bugs.launchpad.net/bugs/485026
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap in ubuntu.
--
Ubuntu-server-bugs mailing list
Just noting for posterity, as of GnuTLS 2.8.0 (released 2009-05-27) you
can use %VERIFY_ALLOW_X509_V1_CA_CRT in the TLSCipherSuite options to
enable V1 CA certs. I will probably #ifdef the current OpenLDAP patch to
turn it off for GnuTLS = 2.8.0. (Haven't decided on best course of
action yet,
Doug Engert wrote:
The real fix is to get the gnutls people to support certificate
directories, like OpenSSL. Why the rush to convert to gnutls
when it has so many issues. (Licencing issues are low on my list of
reasons.)
Indeed, for a security tool you want a package written by experienced
Mathias, in regards to the wiki you linked above, my preference when
debugging these issues is to recommend debug level 7, which includes
packet traces, instead of debug 1. It's much better (to me) to be able
to see all the traffic, which includes the raw transfer of certificates
and their DER
libldap is now patched in OpenLDAP cvs HEAD. We anticipate releasing a
bugfix-only 2.4.16 release very soon, with this fix included.
--
gnutls regression: failure in certificate chain validation
https://bugs.launchpad.net/bugs/305264
You received this bug notification because you are a member of
If you're referring to Gnome bug 551747, yes, I submitted that bug
report and patch, but it appears to have received no attention upstream
yet.
For the reasons I already listed in my previous comment, resolvconf is a
poor solution. I already tried using it here; it still rewrites the disk
too
** Bug watch added: Email to [EMAIL PROTECTED] #
mailto:[EMAIL PROTECTED]
** Also affects: network-manager via
mailto:[EMAIL PROTECTED]
Importance: Undecided
Status: New
--
dnsmasq with enable-dbus doesn't work properly with NetworkManager
https://bugs.launchpad.net/bugs/192643
Just a few comments on prioritizing this wishlist item - I think using
this feature should be the default on any desktop install; using dnsmasq
improves all name resolver lookup response times, and by eliminating
rewrites to /etc/resolv.conf it makes it a lot easier to run a secure
system with a
Actually Paul, your last comment regarding the bug status here was that
you'd be testing, but you hadn't actually posted a confirmation that
your problem was resolved.
And MikMak still hasn't provided any further details on whatever crash
he's still seeing. So while I'm certain that the patch is
Thanks for the report, a patch for this (ITS#5526) is now in OpenLDAP's
CVS HEAD for testing.
--
dnPrettyNormal: Assertion `pretty != ((void *)0)' failed.
https://bugs.launchpad.net/bugs/234196
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed
Please test this patch and let me know if you can still reproduce this
failure.
http://www.openldap.org/lists/openldap-commit/200805/msg00112.html
--
(ITS#5518) Assertion error in io.c:234: ber_flush2
https://bugs.launchpad.net/bugs/215904
You received this bug notification because you are a
Thanks for catching that. Should also be fixed in OpenLDAP CVS now.
--
dnPrettyNormal: Assertion `pretty != ((void *)0)' failed.
https://bugs.launchpad.net/bugs/234196
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap2.3 in ubuntu.
Thanks for this. I see it crashing in 2.4.7 but not in 2.4.9.
--
(ITS#5527) slapd segfaults when using dynlist
https://bugs.launchpad.net/bugs/218734
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap2.3 in ubuntu.
--
Yes, that helps. Please also print *lc from frame 4, thanks.
--
(ITS#5518) Assertion error in io.c:234: ber_flush2
https://bugs.launchpad.net/bugs/215904
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap2.3 in ubuntu.
--
Hmmm, *lc is completely bogus. 7f3a11313ab0 is clearly in the text
segment of the process, and the values starting from lconn_sasl_sockctx
are ASCII:
00: 6d 70 2f 6f 70 65 6e 6c 64 61 70 32 2e 34 2e 37 mp/openldap2.4.7
01: 2f 6c 69 62 72 61 72 69 65 73 2f 6c 69 62 6c 62
37 matches
Mail list logo
