[SERVER-1764] rpath linking of libmozjs.so causes issues on Ubuntu Created: 09/Sep/10  Updated: 29/Feb/12  Resolved: 30/Aug/11

Status: Closed
Project: Core Server
Component/s: Build
Affects Version/s: 1.4.4
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Clint Byrum Assignee: Eliot Horowitz (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu


Attachments: Text File mongodb-build-changes.patch    
Operating System: Linux
Participants:

 Description   

This is a forwarding of the fix for this bug in Ubuntu

https://bugs.launchpad.net/ubuntu/+source/mongodb/+bug/557024

In building 1.4.4 for Ubuntu Maverick, we've recently added a simple wrapper script that sets LD_LIBRARY_PATH to the current home of the system's xulrunner library.

This is being done because the version of xulrunner changes quite often, breaking any programs that were built against the previous version with rpath embedded.

It would make more sense to provide this wrapper with mongodb on Ubuntu systems than setting rpath. I do know that ultimately, what would make more sense would be a stable ABI in xulrunner and placement in /usr/lib, but for now that seems unlikely.

Below is the wrapper script, which would most likely need to be customized with some variables from the build configuration to work properly.

I've attached a patch to SConstruct and buildscripts/hacks_ubuntu.py that will remove the rpath and use LD_LIBRARY_PATH instead to run smoke tests.

#!/bin/sh

  1. xulwrapper - a tiny wrapper for starting mongodb
    #
  2. Copyright (c) 2010, Canonical Ltd.
  3. Author: Clint Byrum <clint@ubuntu.com>
    #
  4. This program is free software; you can redistribute it and/or modify
  5. it under the terms of the GNU General Public License as published by
  6. the Free Software Foundation; either version 2 of the License, or
  7. (at your option) any later version.
    #
  8. This program is distributed in the hope that it will be useful,
  9. but WITHOUT ANY WARRANTY; without even the implied warranty of
  10. MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  11. GNU General Public License for more details.
    #
  12. You should have received a copy of the GNU General Public License
  13. along with this program; see the file COPYING. If not, write to
  14. the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
  15. Boston, MA 02111-1307, USA.
    #
  16. This wrapper is necessary as xulrunner does not follow normal library sematics
  17. Please see https://bugs.launchpad.net/ubuntu/+source/xulrunner-1.9.2/+bug/286906
  18. for more information.
    #
    export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/xulrunner-`xulrunner-1.9.2 --gre-version`
    bname=`basename $0`
    if [ "$bname" = "xulwrapper" ] ; then
    echo xulwrapper must not be used to wrap itself. Paradox avoided.
    exit 1
    fi
    exec "/usr/lib/mongodb/$bname" "$@"


 Comments   
Comment by Eliot Horowitz (Inactive) [ 30/Aug/11 ]

as of 2.0.0-rc0, using a static sm included in source

Comment by Eliot Horowitz (Inactive) [ 12/Oct/10 ]

So just to be clear about what we're planning on doing.
We'll put full versions of the libraries in our source repo and compile against those.
We'll do full updates to those when new versions come out .
If there are security issues - we'll just replace the old version with new one and release new binaries.

Ok - now your comments above

1) In theory I agree with you 100% In practice, this is very hard. Using boost as an example. We currently support boost 1.33+. This is very hard for us as we have many forks in the code, and is problematic because we would like to use new features. Further, we have found bugs in certain versions (1.37) for example. So now, when you cross that with the number of distributions we need to support, it becomes quite complex. Many users run on centos for example which has old versions of boost that are unusable. So we have to have some sort of ability to statically link.

2) We will have an option to use system libraries when they work. If we can make mongo run great using all system libraries on ubuntu 10.10 for example, there is no reason we wont' do that. But that seems to be the exception and not the rule.

3) I'm all in favor of getting them to be more backwards compatible, but until that happens, we have to have a solution. Note we are considering moving away from spidermonkey/xulrunner because of this, which might make things simpler.

So - we really do want to work with the library maintainers, its just proven to be very difficult. Maybe that's because we haven't had a great ubuntu/debian resource to work with. If you're up for it - let us know

Comment by Clint Byrum [ 12/Oct/10 ]

Eliot, thank you for the enumeration of reasons behind this decision.

I'd like to offer some counter points.

  • It is the library distributor's responsibility to work around these bugs. If we are lagging on a library in Ubuntu, and MongoDB says "we only support that library after version X", then this is not a concern of MongoDB, but a concern of ours. I don't know how another library can "make your code fragile". Your code should be well encapsulated and deal with any of the underlying problems of said libraries, or at the very least, refuse to support older un-patched versions. By statically linking or embedding these libraries, you are basically forking them.

-On a side note, if you won't support releases compiled against system libraries, then your software will have to be moved to the 'multiverse' archive in Ubuntu (which many users do not enable, and which does not receive any support from the Ubuntu community)

  • Agreed, xulrunner / spidermonkey is a problem. But it seems what you're proposing is to fork it, so that you can patch older versions, instead of upgrading versions when there are urgent security issues. I am in support of this and think other projects that use xulrunner right now would probably rally behind an effort to resolve upstream's lack of API/ABI stability. However, embedding it just means that you are asking system administrators to do a lot of extra leg work to ensure their systems are secure. When xulrunner reports a security problem, they're not going to list mongodb, so you're going to have to report this as your own security vulnerability, which has now doubled the noise that one problem generates.

I'm sure this bug report is not the right place to have this discussion, so I would appreciate it if you could forward it to the appropriate place, or inform me personally of where to go to discuss this further.

Comment by Eliot Horowitz (Inactive) [ 12/Oct/10 ]

Our current plan is to statically link by default, and optionally use system libraries.
The reasons are as follows

  • every distro has different versions of libraries, many of which are buggy, and makes our code fragile and leads to bugs
  • xulrunner is a very moving target. even minor versions change apis in incompatible way
  • we already have to link statically for main tgz builds

Now I don't mean fully static, i.e. pthread, libc, etc.. are still dynamic. but boost, pcre, spidermonkey will by default be not only static, but the source will be in the mongo repo so we can pin to versions, etc..

Comment by Clint Byrum [ 10/Oct/10 ]

I beg of you not to statically link, and to at least keep the default build method to the system libraries.

Static linking means never knowing if your mongodb instance is vulnerable to security problems in underlying libraries. I don't think I have to remind anyone of the zlib problems of y'ore. With xulrunner's libmozjs.so already a bit of a mess and constantly releasing to solve security issues, statically linking would just be a nightmare.

By using the system libraries, you give your sysadmins a fighting chance to secure their systems by upgrading vulnerable libraries.

I do actually like the idea of splitting libmozjs.so into its own package:

$ ldd /usr/lib/xulrunner-1.9.2.10/libmozjs.so
linux-vdso.so.1 => (0x00007fff017ff000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007fc0cc0a4000)
libplds4.so => /usr/lib/libplds4.so (0x00007fc0cbea0000)
libplc4.so => /usr/lib/libplc4.so (0x00007fc0cbc9a000)
libnspr4.so => /usr/lib/libnspr4.so (0x00007fc0cba5f000)
libdl.so.2 => /lib/libdl.so.2 (0x00007fc0cb85b000)
libm.so.6 => /lib/libm.so.6 (0x00007fc0cb5d7000)
libstdc+.so.6 => /usr/lib/libstdc+.so.6 (0x00007fc0cb2d1000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fc0cb0bb000)
libc.so.6 => /lib/libc.so.6 (0x00007fc0cad37000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc0cc5e9000)

Thats a very reasonable set of dependencies, no pango/cairo/etc.

Please file a bug in Ubuntu requesting this. (The Developer Summit is coming up at the end of October, so now is a good time to start talking about changes like this). In fact even better would be to have the xulrunner upstream team agree to support this like a normal library (they currently do not guarantee ABI compatibility).

But again, Please please please do not statically link or abandon the system libraries in the name of convenience at build time.. as it will just make things inconvenient and insecure later.

Comment by Eliot Horowitz (Inactive) [ 09/Oct/10 ]

the build system is going to change to not use system libraries at all since they are too messy in general

Comment by Mark Renouf [ 09/Oct/10 ]

Is it out of the question to simply fix the packaging so Mongo db is statically linked with libmozjs? This would eliminate an awfully long list of unecessary dependencies:

i --\ xulrunner-1.9.2 1.9.2.10+b 1.9.2.10+b
Source Package: xulrunner-1.9.2
--\ Depends (25)
— libasound2 (> 1.0.22)
— libatk1.0-0 (>= 1.29.3)
— libc6 (>= 2.11)
— libcairo2 (>= 1.6.0)
— libdbus-1-3 (>= 1.0.2)
— libdbus-glib-1-2 (>= 0.78)
— libfontconfig1 (>= 2.8.0)
— libfreetype6 (>= 2.2.1)
— libgcc1 (>= 1:4.1.1)
— libglib2.0-0 (>= 2.23.5)
— libgtk2.0-0 (>= 2.18.0)
— libhunspell-1.2-0 (>= 1.2.8)
— libidl0
— libnspr4-0d (>= 4.7.3-0ubuntu1~)
— libnss3-1d (>= 3.12.6)
— libpango1.0-0 (>= 1.14.0)
— libpixman-1-0 (>= 0.11.2)
— libsqlite3-0 (>= 3.6.22)
— libstartup-notification0 (>= 0.10)
— libstdc++6 (>= 4.1.1)
— libx11-6 (>= 0)
— libxext6
— libxrender1
— libxt6
— zlib1g (>= 1:1.1.4)

Generated at Thu Feb 08 02:57:58 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.