libcap not found => Fixed in SVN

[Ron Gage]

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.

[Paul Kronenwetter]

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.

[Frank Szczerba]

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.

[Frank Mehnert]

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.

[Ron Gage]

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.

[Frank Mehnert]

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

[Frank Szczerba]

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?

[Frank Mehnert]

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).