Re: POSIX CAP_DAC_READ_SEARCH doesn't bypass file read permissions?

["Serge E. Hallyn" <serue@us.ibm.com>]

Quoting Mike Kazantsev (mk.fraggod@gmail.com):
> 
> 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.

To be sure, are you saying that you've tested with CAP_DAC_OVERRIDE and
that works?  Are you running with selinux enforcing?

Note my own test on 2.6.33-rc2-00007-g85d1bb6 succeeds...

> 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