]> git.ipfire.org Git - thirdparty/e2fsprogs.git/commit
AOSP: Standarize on VFS_CAP_REVISION_2
authorNick Kralevich <nnk@google.com>
Mon, 27 Nov 2017 22:07:42 +0000 (14:07 -0800)
committerTheodore Ts'o <tytso@mit.edu>
Mon, 26 Feb 2018 18:33:22 +0000 (13:33 -0500)
commit6ddf78d22d646c301f37d5c210c7c2cce8d92bb4
tree5753b1f61ebee32c61852ac6bbda3b8bea2bacca
parent5177795824af1ba40a416c7c4089b399a86551c6
AOSP: Standarize on VFS_CAP_REVISION_2

In https://github.com/torvalds/linux/commit/8db6c34f1dbc8 , namespaced
file capabilities were introduced. That change updated VFS_CAP_REVISION
from VFS_CAP_REVISION_2 to VFS_CAP_REVISION_3.

Android code is written assuming v2 capabilities, and the code will
break if we naively try to treat a v2 structure as a v3 structure.
So don't even try.

Android kernels prior to v4.14 will not support this extended capability
structure, so attempting to set such capabilities will ultimately fail.

With 8db6c34f1dbc8, it appears that attempting to read a v3 capabilities
xattr will always downgrade the capability to a v2 capability, so it
really doesn't make sense to look for a v3 capability.

Android capabilities are only created at /system and /vendor filesystem
creation time by host tools. Android processes, within or outside a
namespace, are not permitted CAP_SETFCAP
(https://android-review.googlesource.com/c/platform/system/sepolicy/+/547801/1/public/domain.te
line 1101). So we should never have to deal with a v3 capability other
than those that might appear on the /system / /vendor partition at a
future date by a future author.

Bug: 69617725
Test: build/test/boot/CTS passes
Change-Id: I7f9ed62b0a539f705d697113d007f0e7379221ea
From AOSP commit: b256c96940e8e709456f0dc29cce5bf8285f687d
contrib/android/perms.c