Quoting Mike Kazantsev (mk.fraggod@xxxxxxxxx): > On Mon, 28 Dec 2009 10:40:54 +0500 > Mike Kazantsev <mk.fraggod@xxxxxxxxx> wrote: > > > On Sun, 27 Dec 2009 16:06:10 -0600 > > "Serge E. Hallyn" <serue@xxxxxxxxxx> wrote: > > > > > Quoting Mike Kazantsev (mk.fraggod@xxxxxxxxx): > > ... > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html