From: Mike Kazantsev <mk.fraggod@gmail.com>
To: linux-fsdevel@vger.kernel.org
Subject: Re: POSIX CAP_DAC_READ_SEARCH doesn't bypass file read permissions?
Date: Mon, 28 Dec 2009 12:03:52 +0500 [thread overview]
Message-ID: <20091228120352.4b893fcc@malediction> (raw)
In-Reply-To: 20091228104054.09ddce06@malediction
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),
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
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.
Posix 1003.1e draft and capabilities(7) tells that CAP_DAC_READ_SEARCH
should bypass read permissions as well:
This capability shall override file mode read and search access
restrictions when accessing an object...
...but in practice, for some reason, in vanilla kernel, it doesn't, as
quoted below (test.c source can be seen in a thread-starter post).
>
> Basically, that's what I'm seeing:
>
> # uname -a
> Linux alpharius 2.6.32.2-fg.minion32 #1 SMP Mon Dec 28 09:52:53 YEKT
> 2009 i686 Genuine Intel(R) CPU T2600 @ 2.16GHz GenuineIntel
> GNU/Linux
> # gcc test.c -lcap-ng -o /test
> # setcap 'cap_dac_read_search=ep' /test
>
> # getcap /test
> test = cap_dac_read_search+ep
>
> # touch /root/test{1,2}
> # chmod 600 /root/test1
> # chmod 644 /root/test2
>
> # ls -ld /root/{,test{1,2}}
> drwx------ 21 root root 4.0K Dec 28 09:21 /root/
> -rw------- 1 600 root 0 Dec 28 09:21 /root/test1
> -rw-r--r-- 1 644 root 0 Dec 28 09:21 /root/test2
>
> # su -s /bin/zsh nobody
>
> % ls -ld /root/{,test{1,2}}
> ls: cannot access /root/test1: Permission denied
> ls: cannot access /root/test2: Permission denied
> drwx------ 21 root root 4.0K Dec 28 09:21 /root/
>
> % /sbin/getcap /test
> /test = cap_dac_read_search+ep
>
> % /test /root/test1
> Capability: 1, error: Permission denied
>
> % /test /root/test2
> Capability: 1,
>
> % exit
>
> # setcap 'cap_dac_override=ep' /test
> # su -s /bin/zsh nobody
> % /sbin/getcap /test
> /test = cap_dac_override+ep
> % /test /root/test1
> Capability: 0,
> % /test /root/test2
> Capability: 0,
>
--
Mike Kazantsev // fraggod.net
next prev parent reply other threads:[~2009-12-28 7:04 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 [this message]
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=20091228120352.4b893fcc@malediction \
--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).