2

Before invoking chmod() on a directory, if the caller does not own the directory, I would like to test that the caller has the CAP_FOWNER capability.

From searching, it seems that I should be able to test for the CAP_FOWNER capability by calling capable(CAP_FOWNER) -- but capable() is not among my man pages and does not seem to be exported by <linux/capability.h>.

What's the right include file for capable(), or alternatively, what's the simplest/best way to test for a linux capability?

Eric Westbrook
  • 53
  • 6

2 Answers2

4

I think that capable() is available within the kernel sources, but not for general use. If you are writing a device driver or module then it should be available.

If you are writing a user space program, then you might be able to use functions provided by libcap; see man capabilities(7) and man libcap(3). I'd suggest #include <sys/capability.h> and use cap_get_proc() and possibly CAP_IS_SUPPORTED(CAP_FOWNER).

If that's no good the obvious workaround is to attempt chmod() on the directory and handle possible failure.

pevik
  • 4,523
  • 3
  • 33
  • 44
mhawke
  • 84,695
  • 9
  • 117
  • 138
  • 3
    This put me on the right track. The solution boils down to these calls: `cap_t cap = cap_get_proc(); cap_flag_value_t v = 0; cap_get_flag(cap, CAP_FOWNER, CAP_EFFECTIVE, &v);` – Eric Westbrook Apr 27 '17 at 14:00
2

Before invoking chmod() on a directory, ... I would like to test that the caller has the CAP_FOWNER capability.

Do you have a reason to do that in the application side? If a process calls chmod() (or any other syscall), the kernel will in any case check if the process is allowed to do that, and return EPERM or EACCES if not. Detecting that is a very easy test on the application side, and something the application needs to do in any case, as the application may not be aware of all access-control done by the kernel. (Think e.g. SELinux.)

In general, testing first sounds a lot like a Time of check to time of use problem. With an unprivileged process it's not a problem, but if your process does some work on behalf of another user (with the processes actual privilege being higher than it wants to grant the user), it quickly becomes one.

ilkkachu
  • 6,221
  • 16
  • 30