VirtualBox

Ticket #2859 (closed defect: fixed)

Opened 5 years ago

Last modified 5 years ago

libcap not found => Fixed in SVN

Reported by: rongage Owned by:
Priority: major Component: host support
Version: VirtualBox 2.1.0 Keywords: Missing file, libcap
Cc: Guest type: Linux
Host type: Linux

Description

Tried to run the new VirtualBox 2.1.0. Got the following error:

error while loading shared libraries: libcap.so.1: cannot open shared object file: No such file or directory

Searching my system via "find / | grep -i libcap" returns no file by that name.

Change History

comment:1 Changed 5 years ago by kronenpj

Which distribution of Linux are you using? This is somewhat important as, for instance, Gentoo has progressed past libcap v1.x onto v2.x while RHEL/CentOS are still running the older versions. It'll also let people ask intelligent questions and, possibly, let you know how to obtain and install the appropriate package.

comment:2 Changed 5 years ago by fszczerba

Are any of the pre-built binaries compiled with libcap.so.2? I've been trying to update the Gentoo package for VirtualBox, but would really prefer to use the newer, more secure libcap2.

comment:3 Changed 5 years ago by frank

AFAIR we compile against libcap1 on every distribution. Actually we need that library only very rarely (two calls to cap_set_proc() in SUPR3HardenedMain.cpp and I plan to change these calls to using direct syscalls to prevent these library problems on Linux.

comment:4 Changed 5 years ago by rongage

This problem occurred on Slackware 12. I found and installed the proper libcap and everything is working. It all just kinda caught me off guard - especially since this hasn't happened in the past like with 2.0.4.

comment:5 Changed 5 years ago by frank

I already explained it elsewhere: We need CAP_NET_RAM for ICMP support in guests on Linux hosts.

comment:6 Changed 5 years ago by fszczerba

Frank,

Using direct syscalls will insulate you from the library dependency but might make you kernel-dependent. I got the impression from some of the lkml articles that this is a potential area for API churn, and the libcap interface is meant to insulate against that. I think the interface you're using might be stable enough that that's not an issue, just be sure you're not jumping out of the frying pan and into the fire.

I looked at the code yesterday. The calls you are using seem to be ABI-compatible between libcap1 and libcap2. I'm using a local symlink in the VirtualBox install directory (/opt/VirtualBox/libcap.so.1 -> ../../lib/libcap.so.2) to satisfy the linker and everything seems perfectly stable (for several days now). I know this is generally a bad idea, but since Gentoo does not have a libcap1 package available in portage any longer this works for me.

Maybe a better long-term solution is to wrap the binary-only pieces in a partially-compiled and linked package that does not reference any system libraries, then allow the user/disto maintainer to finish the build and link to the proper libraries for their system?

comment:7 Changed 5 years ago by frank

  • Summary changed from libcap not found to libcap not found => Fixed in SVN

I don't think that partial compiling is applicable. In r15871 I've changed the code to use direct kernel calls to prevent the dependency to libcap. We need only one system call (capset). If the kernel interface would change, we would adapt that code as well. This is actually not much different as compiling against another libcap library (which would be necessary if the kernel interface changes).

comment:8 Changed 5 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use