Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 196667

Summary: app-emulations/vmware-server-1.0.4 vmware-authd is binary incompatible with gentoo's pam_ldap.so module (linked against openssl 0.9.8)
Product: Gentoo Linux Reporter: Daniel <deepee>
Component: New packagesAssignee: Gentoo VMWare Bug Squashers [disabled] <vmware+disabled>
Status: RESOLVED DUPLICATE    
Severity: major CC: cardoe
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: Build instructions bundled in a shell script, used to compile a special libldap.so liblber.so to support vmware-authd against pam_ldap

Description Daniel 2007-10-21 21:25:51 UTC
vmware's (closed-source) products are linked against the very old 0.9.7-OpenSSL library products. I just emerged vmware-server-1.0.4 some hours ago.

Authentication against LDAP-Server running under "modern Distributions" (using /etc/pam.d/vmware-authd using pam_ldap.so and/or nss_ldap) fails completely, because the ldap-libraries are compiled against OpenSSL 0.9.8, while vmware needs OpenSSL-0.9.7 and they don't like to talk to each other.

Although the problem was discoverd already in the year 2006, vmware do not offer a solution for modern linux distributions (e.g. Gentoo).
A detailed problem description is available from the VMware-Community-Forum: http://www.vmware.com/community/message.jspa?messageID=424898

As long as VMware Inc. is not willing/able to upgrade there products to use openssl version 0.9.8 the only possible currently "best" solution from customers' point of view is probably available here:

http://darkness.codefu.org/wordpress/2007/07/28/283#comments

I haven't tested the above solution myself (lack of time) But I will test it the next days.

My Gentoo-based LDAP-Server and Services are running completely fine here. I'm using (Open)LDAP within apache, cyrus-imapd, sendmail, tomcat, suqid, sasl, clamav, spamass, nss_ldap/pam_ldap for shell access and so on, with no problem at all.

If you do not have an ldap-infrastructure available, please let me know if I should test a bugfixed ebuild within my environment...

Thanks a lot for the current ebuilds!
Cheers Daniel

Reproducible: Always

Actual Results:  
Oct 21 22:12:14 tony slapd[21032]: conn=702 op=0 STARTTLS
Oct 21 22:12:14 tony slapd[21032]: conn=702 op=0 RESULT oid= err=0 text=
Oct 21 22:12:14 tony slapd[21032]: conn=702 fd=16 closed (TLS negotiation failure)

Expected Results:  
Authentication vmware-authd using /etc/pam/vmware-authd using pam_ldap.so or even system-auth

Portage 2.1.3.9 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.22-gentoo-r5 i686)
=================================================================
System uname: 2.6.22-gentoo-r5 i686 Intel(R) Pentium(R) M processor 1.80GHz
Timestamp of tree: Sun, 21 Oct 2007 00:50:01 +0000
ccache version 2.4 [enabled]
app-shells/bash:     3.2_p17
dev-java/java-config: 1.3.7, 2.0.33-r1
dev-lang/python:     2.3.5-r3, 2.4.4-r5
dev-python/pycrypto: 2.0.1-r6
dev-util/ccache:     2.4-r7
sys-apps/baselayout: 1.12.9-r2
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.61-r1
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.18-r1
sys-devel/gcc-config: 1.3.16
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.22-r2
ACCEPT_KEYWORDS="x86"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
.
..
...
....
.....
Comment 1 Mike Auty (RETIRED) gentoo-dev 2007-10-21 23:36:54 UTC
Sorry Daniel, I realize it's a bug, but you seem quite aware that it's an upstream bug.  How would you like us to help?

We can possibly add a note at the end of the ebuild, but I'm not sure there's a very clean way of ensuring that openldap is compiled against the old openssl and that it's only done when you need ldap support through pam (and not just that you happen to have openldap, openssl and vmware installed on the same box).  If you can think of a solution, we'd welcome it, but I don't really see what we can do?

I'm going to mark this bug as UPSTREAM because we've really got our hands tied here, but if you disagree, please reply here and we'll reopen it...
Comment 2 Daniel 2007-10-22 22:27:46 UTC
Created attachment 134144 [details]
Build instructions bundled in a shell script, used to compile a special libldap.so liblber.so to support vmware-authd against pam_ldap

I got vmware-server's vmware-authd (using gentoo's standard shipped pam_ldap) finally running. Therefore I adepted the idea and instructions behind the above mentioned blog posting. My changes:

1.) ssl config options are wrong, "--" should not be used (gentoo additionally uses "threads")
2.) CPPFLAGS are useless; used CFLAGS=... instead
3.) ln -s install command's are a little bit "reversed" or I didn't understood the paths ;-)

I build the latest (openldap 2.3.38) libldap.so and liblber.so which are compiled using openssl 0.9.7m header files. Testing this build client-binaries explicitly using the openssl-0.9.7-libs starting the also compiled ldapsearch command line tool:

LD_LIBRARY_PATH="PATH/TO/BUILD/LDAPLIBS" ldapsearch -x-Z -h "..." -D "..." -W

worked like a charm! ;-)

Attached to this message you'll find the shell script I used to compile libldap 2.3.38 against openssl and install the lib under vmware-server's library directory.

After the script has been run I manually extended the vmware-authd's xinetd-configuration file "/etc/xinetd.d/vmware-authd" by this line:
"env = LD_LIBRARY_PATH=/.../vmware/server/lib/lib/libldap-2.3.so.0:/.../vmware/server/lib/lib/liblber-2.3.so.0"
 Opend a console, entered login and password ----> BINGO! ;-)

cat /etc/xinetd.d/vmware-authd
# default: on
# description: The VMware remote access authentification daemon, using
# custom openldap libs compiled against openssl 0.9.7 to allow usage of
# gentoo's ebuild-shipped "pam_ldap/nss_ldap" to authenticate/authorize
# against ldap directories:
service vmware-authd
{
    disable         = no
    port            = 902
    socket_type     = stream
    protocol        = tcp
    wait            = no
    user            = root
    server          = /opt/vmware/server/sbin/vmware-authd
    env             = LD_LIBRARY_PATH=/opt/vmware/server/lib/lib/libldap-2.3.so.0:/opt/vmware/server/lib/lib/liblber-2.3.so.0
    type            = unlisted
}

Open question:
How can (should?!) this workaraound be integrated into vmware-server ebuild (perhaps by (miss)using "USE=ldap")??? Or should this bug report including this tested workaround and the shell-script, be linked in a message that the ebuild prints after emerge has been run? I leave this decision completely up to you. ;-)

Best regards
Daniel
Comment 3 Mike Auty (RETIRED) gentoo-dev 2007-10-22 22:42:08 UTC
Ok thanks.  I think at best we're going to mention that people looking for LDAP/pam support should see this bug.  I hope that's ok with you, thanks for contributing your work back to the community...  5:)

I've reOPENed this until I add it into the overlay or portage itself.
Comment 4 Doug Goldstein (RETIRED) gentoo-dev 2007-11-30 19:53:21 UTC
Hey Daniel,

Nice work. I've been on a similar crusade to get this fixed speaking with various product managers and such. I've been approaching it from another standpoint to attempt to get them to change the way they build their product. They need to prevent symbols from being exported for libraries that are being linked in as helper libs because when openssl 0.9.9 is released and vmware switches to 0.9.8, we'll have the same problem.

Additionally, simply compiling openldap against Gentoo's latest 0.9.7 version (only one without security issues) didn't fix the problem for me. I had to actually compile it against the openssl libraries they provided.

I'll check out the work you've done on this bug and report back. There was another similar bug to this about nss_ldap that was resolved but I can't remember what fixed it. (It could have been unrelated too.)
Comment 5 Andreas K. Hüttel archtester gentoo-dev 2010-07-14 20:59:57 UTC
This is probably obsolete by now?
Comment 6 Doug Goldstein (RETIRED) gentoo-dev 2010-07-15 15:29:33 UTC
Actually, when Gentoo switches to 1.0.0 of OpenSSL, this issue will crop up again.
Comment 7 Andreas K. Hüttel archtester gentoo-dev 2010-07-15 16:09:39 UTC
(In reply to comment #6)
> Actually, when Gentoo switches to 1.0.0 of OpenSSL, this issue will crop up
> again.
> 

Yes. I'm reading gentoo-dev too... :|

Bug 328355 should handle the slotting, so I'm resolving this one here (slightly unconventinally) as its duplicate...


*** This bug has been marked as a duplicate of bug 328355 ***