From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Serge E. Hallyn" Subject: Re: POSIX CAP_DAC_READ_SEARCH doesn't bypass file read permissions? Date: Mon, 28 Dec 2009 10:22:05 -0600 Message-ID: <20091228162205.GA11756@us.ibm.com> References: <20091226233012.38d67cf5@coercion> <20091227220610.GA19083@us.ibm.com> <20091228104054.09ddce06@malediction> <20091228120352.4b893fcc@malediction> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: Mike Kazantsev Return-path: Received: from e1.ny.us.ibm.com ([32.97.182.141]:33546 "EHLO e1.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750905AbZL1QWN (ORCPT ); Mon, 28 Dec 2009 11:22:13 -0500 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e1.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id nBSGJMu9010930 for ; Mon, 28 Dec 2009 11:19:22 -0500 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBSGMBtt130814 for ; Mon, 28 Dec 2009 11:22:12 -0500 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nBSGM2Kh031668 for ; Mon, 28 Dec 2009 09:22:02 -0700 Content-Disposition: inline In-Reply-To: <20091228120352.4b893fcc@malediction> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Quoting Mike Kazantsev (mk.fraggod@gmail.com): > On Mon, 28 Dec 2009 10:40:54 +0500 > Mike Kazantsev wrote: > > > On Sun, 27 Dec 2009 16:06:10 -0600 > > "Serge E. Hallyn" 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