summaryrefslogtreecommitdiffstats
path: root/fs/ecryptfs
diff options
context:
space:
mode:
authorSatyam Sharma <ssatyam@cse.iitk.ac.in>2007-07-17 15:00:08 +0530
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-07-17 12:00:03 -0700
commit3bd858ab1c451725c07a805dcb315215dc85b86e (patch)
tree5d49c4300e350d64fd81eb3230b81f754117e0c1 /fs/ecryptfs
parent49c13b51a15f1ba9f6d47e26e4a3886c4f3931e2 (diff)
downloadop-kernel-dev-3bd858ab1c451725c07a805dcb315215dc85b86e.zip
op-kernel-dev-3bd858ab1c451725c07a805dcb315215dc85b86e.tar.gz
Introduce is_owner_or_cap() to wrap CAP_FOWNER use with fsuid check
Introduce is_owner_or_cap() macro in fs.h, and convert over relevant users to it. This is done because we want to avoid bugs in the future where we check for only effective fsuid of the current task against a file's owning uid, without simultaneously checking for CAP_FOWNER as well, thus violating its semantics. [ XFS uses special macros and structures, and in general looked ... untouchable, so we leave it alone -- but it has been looked over. ] The (current->fsuid != inode->i_uid) check in generic_permission() and exec_permission_lite() is left alone, because those operations are covered by CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH. Similarly operations falling under the purview of CAP_CHOWN and CAP_LEASE are also left alone. Signed-off-by: Satyam Sharma <ssatyam@cse.iitk.ac.in> Cc: Al Viro <viro@ftp.linux.org.uk> Acked-by: Serge E. Hallyn <serge@hallyn.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs/ecryptfs')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud