Mathias: IIRC, the compat workaround only works if you have all users in
the local passwd database. You still won't be able to use sudo, or run
any other setuid binary that uses nss-services, for users that don't
exist in the local passwd database.
--
NSS using LDAP on Karmic breaks 'su' and
The workarounds available AFAIK is:
- install nscd
- or replace libnss-ldap with libnss-ldapd (and nslcd)
Both workarounds worked for me on karmic.
--
NSS using LDAP on Karmic breaks 'su' and 'sudo'
https://bugs.launchpad.net/bugs/423252
You received this bug notification because you are a
Rune: The first solution (nscd) is not waterproof as nscd tends to crash
quite often (and thus revoking your ability to do su or sudo as ldap
user)
--
NSS using LDAP on Karmic breaks 'su' and 'sudo'
https://bugs.launchpad.net/bugs/423252
You received this bug notification because you are a
2010/4/27 Hark ubu...@komkommerkom.com:
Rune: The first solution (nscd) is not waterproof as nscd tends to crash
quite often (and thus revoking your ability to do su or sudo as ldap
user)
i use a combination of LDAP + NSCD + cached credentials (ccreds) and i
can do su or sudo without
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
There is always the chance of something crashing, no matter how you fix this
problem!
Of course having a sudoable (or root) account in the local passwd database
would remove a lot of the uncertainty that comes from relying on network for
resolving users.
Several has commented that nscd is
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
Updating statuses based on Howard feedback in comment 62.
** Changed in: eglibc (Ubuntu Karmic)
Status: New = Invalid
** Changed in: eglibc (Ubuntu Lucid)
Status: New = Invalid
** Changed in: libnss-ldap (Ubuntu Karmic)
Status: New = Invalid
** Changed in: libnss-ldap
Lucid release note:
Upgrading systems configured to use ldap via ssl as the first service in
the nss stack (in nsswitch.conf) leads to a broken nss resolution
afterwards (for example sudo would stop working). A workaround is to
configure ldap to be used after the compat service in nsswitch.conf
According to the reporter this configuration used to work in jaunty.
libgrypt11 version is 1.4.1-2ubuntu1. It seems that something
changed/broke between 1.4.1 and 1.4.4.
--
NSS using LDAP on Karmic breaks 'su' and 'sudo'
https://bugs.launchpad.net/bugs/423252
You received this bug notification
If I can try to summarize the situation on this bug:
- This is a regression from hardy. This use to work on hardy.
- We document using tls for LDAP authentication in the server guide
The most annoying point IMHO, is that someone who has root access to his
server with a LDAP account with sudo,
mathias, could you clarify if there is anything we can do here pre-Lucid
release ?
** Changed in: sudo (Ubuntu Lucid)
Assignee: (unassigned) = Mathias Gug (mathiaz)
--
NSS using LDAP on Karmic breaks 'su' and 'sudo'
https://bugs.launchpad.net/bugs/423252
You received this bug notification
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
Howard, I have longingly looked at libnss-ldapd for almost 4 years now, and
absolutely agree it has a better architecture, cleaner code etc., and is a
sensible long-term migration path. (The other possibly being sssd.)
But multiple test migrations in my LDAP deployments always turned up some
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
I managed to get a core-dump from a test program (a nice little hack
that debugs the test application and core dumps it when it executes the
setuid syscall) that reproduces the bug. The following stack trace might
be of interest:
#0 __nptl_setxid (cmdp=0x7fff1439ad00) at allocatestack.c:1135
#1
** Also affects: libgcrypt11 (Ubuntu)
Importance: Undecided
Status: New
--
NSS using LDAP on Karmic breaks 'su' and 'sudo'
https://bugs.launchpad.net/bugs/423252
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libnss-ldap in
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
Howard, a quick google didn't show much other than package info for
libnss-ldapd. Do you have any links to documentation that might be of
use? We're about to do a major ldap rollout for our servers at work and
I want to know as much as I can ahead of time.
--
NSS using LDAP on Karmic breaks
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'
Yes, the problem went away, when I installed libldap, which I compiled
with openssl.
apt-get source libldap
Edit openldap-2.4.21/debian/configure.options to change --with-tls=gnutls to
--with-tls=openssl
(do not forget to install the libssl-dev package and build-depends for openldap)
I can confirm that this is a show stopper for lots of companies. For
example in the company where I work we are planning to upgrade lots of
machines from Hardy to Lucid, but this won't happen before this bug has
been solved. And I don't expect we are going to compile ldap with a
custom option on
Why would openssl be a problem?
It is included in debian http://packages.debian.org/sid/openssl
--
NSS using LDAP on Karmic breaks 'su' and 'sudo'
https://bugs.launchpad.net/bugs/423252
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
On Wed, Apr 14, 2010 at 06:35:10AM -, Bolesław Tokarski wrote:
I do not know if this solution would be acceptable for Debian, due to
some license concerns.
Ubuntu follows the same principle as Debian in terms of licensing.
Openldap cannot be compiled with openssl due to the conflict
Debugging this one proved to be pretty tricky. GDB has a nasty habit of
loosing control over the debuggee (bug #563361). I've managed to find
out that setuid is called from nptl/allocatestack.c:__nptl_setxid in
eglibc, but I haven't succeeded in getting a stack trace. If I
understand things
I worked around the problem by recompiling libldap2 with openssl. It
seems there is either a bug in GnuTLS or some kind of interface bug
between ldap and gnutls.
This is not the first problem I encountered with openldap and gnutls.
Maybe we should link openldap with openssl in the distro?
--
I agree. gnutls is often the source of strange, unforseen errors. I'd
also vote to replace it with the reliable and proven openssl.
So linking libldap2 with openssl fixes this issue?
--
NSS using LDAP on Karmic breaks 'su' and 'sudo'
https://bugs.launchpad.net/bugs/423252
You received this bug
I was suspecting this was the case, I was meaning to try this myself but
got caught up in doing more urgent things (paper deadline). I think
liking with OpenSSL is an acceptable solution if this fixes this issue.
Anyway this bug is really a show stopper for using Ubuntu in a lot of
companies, so
I'm also experiencing this issue in the latest Lucid beta. When I
started investigating, I found that the system does not obey the setuid
bit on /bin/su if I'm running it as a user in the LDAP database.
However, running as a local user works as expected.
--
NSS using LDAP on Karmic breaks 'su'
@Andreas: wow, that explains a lot, especially why installing nscd seems to
help.
Because if nscd is not running, the libnss_ldap function getpwnam() resolves to
will run in process, and someone in there (libgnutls ?) does the priviledge
drop.
Good catch, let's investigate further.
** Changed
Finally got a chance to revisit this after post #29 above. For that
servers config I still had a local /etc/passwd entry for the affected
account and so was not triggering the described su and sudo symptoms.
On Karmic with:
libnss-ldap 261-2.1ubuntu4
sudo 1.7.0-1ubuntu2.1
login
Bug still present under the latest lucid beta.
--
NSS using LDAP on Karmic breaks 'su' and 'sudo'
https://bugs.launchpad.net/bugs/423252
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libnss-ldap in ubuntu.
--
Ubuntu-server-bugs
** Changed in: sudo (Ubuntu Lucid)
Importance: Undecided = Medium
** Changed in: libnss-ldap (Ubuntu Lucid)
Importance: Undecided = Medium
--
NSS using LDAP on Karmic breaks 'su' and 'sudo'
https://bugs.launchpad.net/bugs/423252
You received this bug notification because you are a member
Since 8.10 (Intrepid), the Ubuntu Server Guide section regarding LDAP
authentication references the auth-client-config and libnss-ldap
packages. However, following these instructions when using LDAP with
TLS breaks various authentication functions in 9.10 (Karmic). After
determining this issue
It would help to understand if the problem is with eglibc, sudo, or
libnss-ldap.
** Package changed: glibc (Ubuntu) = eglibc (Ubuntu)
** Also affects: libnss-ldap (Ubuntu)
Importance: Undecided
Status: New
** Also affects: eglibc (Ubuntu Lucid)
Importance: Undecided
Status:
39 matches
Mail list logo
