linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Kazantsev <mk.fraggod@gmail.com>
To: linux-fsdevel@vger.kernel.org
Subject: POSIX CAP_DAC_READ_SEARCH doesn't bypass file read permissions?
Date: Sat, 26 Dec 2009 23:30:12 +0500	[thread overview]
Message-ID: <20091226233012.38d67cf5@coercion> (raw)

[-- Attachment #1: Type: text/plain, Size: 2101 bytes --]


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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

             reply	other threads:[~2009-12-26 18:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-26 18:30 Mike Kazantsev [this message]
2009-12-27 22:06 ` POSIX CAP_DAC_READ_SEARCH doesn't bypass file read permissions? Serge E. Hallyn
2009-12-28  5:40   ` Mike Kazantsev
2009-12-28  7:03     ` Mike Kazantsev
2009-12-28 16:22       ` Serge E. Hallyn
2009-12-28 23:59         ` Mike Kazantsev
2009-12-29  5:20   ` Serge E. Hallyn
2009-12-29 11:53     ` Mike Kazantsev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091226233012.38d67cf5@coercion \
    --to=mk.fraggod@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).