I have a custom application which comes with its own libstdc++.so.6 and it requires cap_net_admin and cap_net_raw to work properly.
Before I set file capabilities it starts without problems but when I set:

/sbin/setcap cap_net_admin,cap_net_raw+pie /path/to/customapp

it gives the following error:

./customapp: /usr/lib/i386-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.19' not found (required by ./customapp)

When I do readelf -d it shows that it is looking for libraries at the correct location:

0x0000000f (RPATH)                      Library rpath: [$ORIGIN/lib]

and ldd ./customapp shows the same:

libstdc++.so.6 => /path/to/./lib/libstdc++.so.6 (0xb75ed000)

I followed the advice given here and added new shared library path to ld.so(1):

echo "/path/to/lib" > /etc/ld.so.conf.d/customapp.conf && ldconfig

I tried this on Ubuntu 14.04 and it works well there so why doesn't it work on Debian?

OS: Debian GNU/Linux 7.6 (wheezy)
uname -a: Linux debsrv 3.2.0-4-686-pae #1 SMP Debian 3.2.60-1+deb7u3 i686 GNU/Linux

  • I presume you've checked man ld.so on both systems? Some systems ignore $ORIGIN for setuid executables for security reasons, and it's easy to see how that could be extended to capabilities. Perhaps there's a policy or configuration setting to control this? – BobDoolittle Oct 1 '14 at 13:19
  • You're right. @ORIGIN doesn't get expanded for executables with file capabilities (1). – Ragnar Oct 1 '14 at 15:38
  • So the real questions are: 1. why a difference on these two platforms (Ubuntu vs Debian)? 2. why weren't you able to fix this with ld.so.conf.d? Different versions of ld.so or kernel perhaps? Or different default system settings that somehow affect this behavior? I would expect the man page to correctly reflect the behavior. If not, that's a bug. – BobDoolittle Oct 1 '14 at 16:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.