Bug 14913 - POSIX capability CAP_DAC_READ_SEARCH does not bypass filesystem permissions
Summary: POSIX capability CAP_DAC_READ_SEARCH does not bypass filesystem permissions
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Other
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: other_other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-28 10:34 UTC by Mike Kazantsev
Modified: 2009-12-29 12:04 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.32.1, 2.6.32.2, 2.6.33-rc2
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
Simple open() test (520 bytes, text/plain)
2009-12-28 10:34 UTC, Mike Kazantsev
Details
Patch to fix the problem (works with at least 2.6.32.2 and 2.6.33-rc2) (1.07 KB, patch)
2009-12-29 11:58 UTC, Mike Kazantsev
Details | Diff

Description Mike Kazantsev 2009-12-28 10:34:20 UTC
Created attachment 24325 [details]
Simple open() test

Posix 1003.1e draft and capabilities(7) tells that CAP_DAC_READ_SEARCH
should bypass read permissions:

  This capability shall override file mode read and search access
  restrictions when accessing an object...

In reality it bypasses directory modes, but not file's.


Following is the results of open(2) from a process with the capability in question enabled (test.c source is attached).
Tests are against non-SELinux-enabled (or any other LSM-enabled) kernel.
Filesystem is ext4, but the same behavior was observed with xfs and reiserfs.


  # gcc -lcap test.c -o /test
  # setcap 'cap_dac_read_search=ep' /test

  # 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 root root    0 Dec 28 09:21 /root/test1
  -rw-r--r--  1 root 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
  Process capabilities: = cap_dac_read_search+ep; Access: error (13) - Permission denied
  % /test /root/test2
  Process capabilities: = cap_dac_read_search+ep; Access: success!


Naturally, expected result is a success to open both files, since cap_dac_read_search capability is effective.

In fact, sources from the tip of master branch of Serge E. Hallyn's tree (at least true for ea21e0baaa972aa0b4) doesn't suffer from this problem.

Related thread: http://thread.gmane.org/gmane.linux.file-systems/37470
Comment 1 Mike Kazantsev 2009-12-29 11:58:09 UTC
Created attachment 24342 [details]
Patch to fix the problem (works with at least 2.6.32.2 and 2.6.33-rc2)
Comment 2 Mike Kazantsev 2009-12-29 12:04:40 UTC
Versions lesser than 2.6.32 are unaffected by the bug, so it looks like a regression.


Serge E. Hallyn has already fixed the issue, providing the attached patch (see the discussion thread in the original post). From the patch itself:

  Subject: [PATCH 1/1] generic_permission: MAY_OPEN is not write access

  generic_permission was refusing CAP_DAC_READ_SEARCH-enabled
  processes from opening DAC-protected files read-only, because
  do_filp_open adds MAY_OPEN to the open mask.

  Ignore MAY_OPEN.  After this patch, CAP_DAC_READ_SEARCH is
  again sufficient to open(fname, O_RDONLY) on a file to which
  DAC otherwise refuses us read permission.

Note You need to log in before you can comment on or make changes to this bug.