summaryrefslogtreecommitdiff
path: root/libutils/Unicode.cpp
diff options
context:
space:
mode:
authorNick Kralevich <nnk@google.com>2017-11-27 13:34:19 -0800
committerNick Kralevich <nnk@google.com>2017-11-27 14:17:42 -0800
commit65b8d749f71d7962831e87600dd6137566c3c281 (patch)
treed95daf31d84f5abca54233396eb831193e69c229 /libutils/Unicode.cpp
parenta22780401569df71d3774679f2097efec0bc767f (diff)
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: I0378b3f1195dc62dbeb771944ab378c881441118
Diffstat (limited to 'libutils/Unicode.cpp')
0 files changed, 0 insertions, 0 deletions