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
next prev parent 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).