Good day.
I'm not sure if it's the right list, but I believe the checks I'm
bumping against should be done in filesystem code.
I haven't used POSIX capabilities until now, and is trying to solve
classical backup case, when rsync process need to read whole fs, yet I
don't want to give it any extra privileges or root-level access to
everything.
CAP_DAC_READ_SEARCH seem to be well-suited and sufficient for the task,
according to docs:
Bypass file read permission checks and directory read and execute
permission checks.
I can see it bypassing directory checks, but it fails to bypass file
permission check.
For example, following code fails with "Capability: 1, Error: Permission
denied" on any file with 0000 permissions or, for example,
"/root/test1" file with 700 permissions, while succeeding for
"/root/test2" file with 755, with "/root" path having 700 mode and uid
of test-user is non-root.
Getcap of a binary gives "= cap_dac_read_search+eip", which is
consistent with capng_have_capability result.
#include <stdio.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <cap-ng.h>
int main(int argc, char **argv) {
printf( "Capability: %d, ",
capng_have_capability(CAPNG_EFFECTIVE, CAP_DAC_READ_SEARCH) );
int fd;
if ((fd = open(argv[1], O_RDONLY)) == -1) {
printf("Error: %s\n", (char*) strerror(errno));
return(1); }
else {
close(fd);
return(0); }
};
I've tried this code with the same result for ext4, reiserfs and xfs.
CAP_DAC_OVERRIDE works for bypassing any permissions, but it's not
quite what I need.
Kernel is 2.6.32.2, with CONFIG_SECURITY_FILE_CAPABILITIES=y and
security labels enabled for all filesystems that support them.
So, now I'm puzzled: is that a normal behavior for this capability?
Am I doing something wrong?
Is there a bug in documentation, or prehaps I misinterpreted it?
Thanks in advance for shedding any light on this mystery.
--
Mike Kazantsev // fraggod.net
Attachment:
signature.asc
Description: PGP signature
