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
Subject: Re: POSIX CAP_DAC_READ_SEARCH doesn't bypass file read permissions?
Date: Mon, 28 Dec 2009 10:22:05 -0600	[thread overview]
Message-ID: <20091228162205.GA11756@us.ibm.com> (raw)
In-Reply-To: <20091228120352.4b893fcc@malediction>

Quoting Mike Kazantsev (mk.fraggod@gmail.com):
> On Mon, 28 Dec 2009 10:40:54 +0500
> Mike Kazantsev <mk.fraggod@gmail.com> wrote:
> 
> > On Sun, 27 Dec 2009 16:06:10 -0600
> > "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > 
> > > 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.
> > ...
> > > 
> > > 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...
> > > 
> > 
> 
> I've ran the test with 6b7b284958d47b77d06745b36bc7f36dab769d9b (tip of
> Linus branch, tagged 2.6.33-rc2) and seeing the same results as quoted
> below.
> Then I checked out the tip of your branch (ea21e0baaa972aa0b4),

Oh, I don't update master on that tree, so that's actually a pretty
old and then heavily patched tree.  My test ran on Linus' latest
(6b7b284958d47b77d06745b36bc7f36dab769d9b) tree.

> compiled with the same settings, rebooted VM, and it worked just as
> it's supposed to.
> 
> Guess I'll try to find the relevant changes, but my experience with C

No no, that's a checkpoint/restart tree with a huge delta :)

> and kernel architecture is very limited, so if you can give any hint of
> the possible cause, I'll be grateful.
> 
> 
> To clarify the situation:
> 
> What I'm trying to do is to bypass file read permissions with
> CAP_DAC_READ_SEARCH capability.
> 
> I've ran the same test with CAP_DAC_OVERRIDE just to see if FS DAC
> bypassing capabilities are working at all, that one does.

Can you send me your .config?  Do you have any posix acl's set?

thanks,
-serge

  reply	other threads:[~2009-12-28 16:22 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 [this message]
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=20091228162205.GA11756@us.ibm.com \
    --to=serue@us.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mk.fraggod@gmail.com \
    /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).