linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Mike Kazantsev <mk.fraggod@gmail.com>
Cc: linux-fsdevel@vger.kernel.org, Al Viro <viro@ftp.linux.org.uk>
Subject: Re: POSIX CAP_DAC_READ_SEARCH doesn't bypass file read permissions?
Date: Mon, 28 Dec 2009 23:20:50 -0600	[thread overview]
Message-ID: <20091229052050.GA23226@us.ibm.com> (raw)
In-Reply-To: <20091227220610.GA19083@us.ibm.com>

Quoting Serge E. Hallyn (serue@us.ibm.com):
> Quoting Mike Kazantsev (mk.fraggod@gmail.com):
> > 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...

Egads, I'm sorry, Mike.  I was sure that if there was any problem it
would be in the exec_permission_lite path, that I had only checked DAC
perms on the path.  In fact, it's the DAC perms on the actual file
which are the problem.  I can reproduce your problem, and the following
patch fixes it.  Please confirm.

>From e923e0c84009c43748ad43d518ba9f702ad3dc1b Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <serue@us.ibm.com>
Date: Mon, 28 Dec 2009 21:11:46 -0800
Subject: [PATCH 1/1] generic_permission: MAY_OPEN is not write access

generic_permission was refusing CAP_DAC_READ_SEARCH-enabled
processes from opening DAC-protected files read-only, because
do_filp_open adds MAY_OPEN to the open mask.

Ignore MAY_OPEN.  After this patch, CAP_DAC_READ_SEARCH is
again sufficient to open(fname, O_RDONLY) on a file to which
DAC otherwise refuses us read permission.

Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
---
 fs/namei.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index 68921d9..b55440b 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -232,6 +232,7 @@ int generic_permission(struct inode *inode, int mask,
 	/*
 	 * Searching includes executable on directories, else just read.
 	 */
+	mask &= MAY_READ | MAY_WRITE | MAY_EXEC;
 	if (mask == MAY_READ || (S_ISDIR(inode->i_mode) && !(mask & MAY_WRITE)))
 		if (capable(CAP_DAC_READ_SEARCH))
 			return 0;
-- 
1.6.0.4


  parent reply	other threads:[~2009-12-29  5:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-26 18:30 POSIX CAP_DAC_READ_SEARCH doesn't bypass file read permissions? Mike Kazantsev
2009-12-27 22:06 ` 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 [this message]
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=20091229052050.GA23226@us.ibm.com \
    --to=serue@us.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mk.fraggod@gmail.com \
    --cc=viro@ftp.linux.org.uk \
    /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).