Having not used setcap, would that also require the setuid bit to be set with ownership as root (like sudo)? And reside on a filesystem without the nosuid mount option?
> would that also require the setuid bit to be set with ownership as root (like sudo)?
Doesn't setuid just change to whichever user owns the file? So with setuid root only needs to own it if you want full administrative privileges.
I also haven't played with setcap myself. My understanding is that capabilities don't rely on file ownership but instead on extended file attributes (which can't be changed by ordinary users on a correctly configured system). So root doesn't need to own the file, but of course granting any capabilities to a binary for which a non-root user has write permission seems like it would be a really bad idea in general.
> And reside on a filesystem without the nosuid mount option?
Yes, it appears the nosuid mount option disables file capabilities. (As one would hope!) But I'm not really seeing how that's an issue since (for example) bind mounts and btrfs subvolume mounts both allow changing the nosuid option.
(man 7 capabilities)
> 1. For all privileged operations, the kernel must check whether the thread has the required capability in its effective set.
> 2. The kernel must provide system calls allowing a thread's capability sets to be changed and retrieved.
> 3. The file system must support attaching capabilities to an executable file, so that a process gains those capabilities when the file is executed.