Debian – Setcap not found in Debian 9

Right; I think I finally understood what is happening - key line I missed is:

Installing with make install...

This means that the make install of the 2.7 source package was run - probably in order to "see" where those files will eventually end up, so as to write those locations in the new .deb? But in any case, the new 2.7 .deb indeed didn't get installed - and that is why it couldn't be removed with dpkg -r, and the executable was still lingering even after dpkg -r.

So to remove this installation after running checkinstall, one should actually call make uninstall from the feh source folder:

$ make uninstall
rm -f /usr/local/share/man/man1/feh.1 /usr/local/share/man/man1/feh-cam.1
rm -f /usr/local/share/man/man1/gen-cam-menu.1
rm -rf /usr/local/share/doc/feh
rm: cannot remove `/usr/local/share/doc/feh/TODO': Permission denied
rm: cannot remove `/usr/local/share/doc/feh/examples/keys': Permission denied
rm: cannot remove `/usr/local/share/doc/feh/examples/themes': Permission denied
rm: cannot remove `/usr/local/share/doc/feh/examples/buttons': Permission denied
rm: cannot remove `/usr/local/share/doc/feh/AUTHORS': Permission denied
rm: cannot remove `/usr/local/share/doc/feh/ChangeLog': Permission denied
rm: cannot remove `/usr/local/share/doc/feh/README': Permission denied
make: *** [uninstall] Error 1

$ sudo make uninstall
rm -f /usr/local/share/man/man1/feh.1 /usr/local/share/man/man1/feh-cam.1
rm -f /usr/local/share/man/man1/gen-cam-menu.1
rm -rf /usr/local/share/doc/feh
rm -f /usr/local/bin/feh /usr/local/bin/feh-cam /usr/local/bin/gen-cam-menu
rm -rf /usr/local/share/feh/fonts
rm -rf /usr/local/share/feh/images

... and then finally I can try the newly created package:

$ sudo dpkg -i feh_2.7-tar.bz2_i386.deb 
Selecting previously deselected package feh.
(Reading database ... 202165 files and directories currently installed.)
Unpacking feh (from feh_2.7-tar.bz2_i386.deb) ...
Setting up feh (2.7-tar.bz2) ...
Processing triggers for man-db ...

$ feh --version
feh version 2.7
Compile-time switches: curl xinerama 

$ sudo dpkg --purge feh
(Reading database ... 202198 files and directories currently installed.)
Removing feh ...
dpkg: warning: while removing feh, directory '/usr/local/share/doc' not empty so not removed.
Processing triggers for man-db ...

$ feh --version
bash: /usr/local/bin/feh: No such file or directory

# or in new terminal 
$ feh --version
The program 'feh' is currently not installed.  You can install it by typing:
sudo apt-get install feh

Oh well.... hope I understood correctly how the process goes now, though..

Until you asked the question I never even heard of this facility in Unix (file capabilities). I found this link which looks to have the solution as to how to make ld.so trust your shared libraries:

• JDK-7157699 : can not run java after granting posix capabilities

excerpt from that post

When one is raising the privileges of an executable, the runtime loader (rtld), better know as ld.so will not link with libraries in untrusted paths. This is the way the ld.so(1) has been designed. If one needs to run such an executable, then you have to add that path to the trusted paths of ld.so, the following describes how to do so:

Fedora 11:
% uname -a
Linux localhost.localdomain 2.6.29.4-167.fc11.i686.PAE #1 SMP Wed May 27 17:28:22 EDT 2009 i686 i686 i386 GNU/Linux

% sudo setcap cap_net_raw+epi ./jdk1.7.0_04/bin/java

% ./jdk1.7.0_04/bin/java -version
./jdk1.7.0_04/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

Its kaput, Ok we are on the same page now, to fix this, create a file such as > this, with the path to libjli.so

% cat /etc/ld.so.conf.d/java.conf
/home/someuser/jdk1.7.0_04/jre/lib/i386/jli

This will add the the pathname to the trusted user path, that ld.so will use, to build its runtime cache, verify if ld.so is seeing it by doing this, need to run it as root, and a reboot may be necessary.

% ldconfig | grep libjli
libjli.so -> libjli.so
.......

Now test java:

% ./jdk1.7.0_04/bin/java -version
java version "1.7.0_04-ea"
Java(TM) SE Runtime Environment (build 1.7.0_04-ea-b18)

and there you have it.....

References

• POSIX file capabilities: Parceling the power of root
• This is the Linux kernel capabilities FAQ
• capabilities man page
• Capability-based security - wikipedia
• Using File Capabilities Instead Of Setuid