From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Kazantsev Subject: Re: POSIX CAP_DAC_READ_SEARCH doesn't bypass file read permissions? Date: Mon, 28 Dec 2009 12:03:52 +0500 Message-ID: <20091228120352.4b893fcc@malediction> References: <20091226233012.38d67cf5@coercion> <20091227220610.GA19083@us.ibm.com> <20091228104054.09ddce06@malediction> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit To: linux-fsdevel@vger.kernel.org Return-path: Received: from lo.gmane.org ([80.91.229.12]:52155 "EHLO lo.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751567AbZL1HEQ (ORCPT ); Mon, 28 Dec 2009 02:04:16 -0500 Received: from list by lo.gmane.org with local (Exim 4.50) id 1NP9eH-0002Tc-Mp for linux-fsdevel@vger.kernel.org; Mon, 28 Dec 2009 08:04:13 +0100 Received: from wall.mplik.ru ([195.58.1.141]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 28 Dec 2009 08:04:13 +0100 Received: from mk.fraggod by wall.mplik.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 28 Dec 2009 08:04:13 +0100 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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), 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