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: I10b4b0472d16c5d9f93c9f3f3685851d0fe75080

1 files changed, 1 insertions, 1 deletions

diff --git a/squashfs-tools/android.c b/squashfs-tools/android.c
index 04c0ad9..a383d2b 100644
--- a/squashfs-tools/android.c
+++ b/squashfs-tools/android.c
@@ -108,7 +108,7 @@ struct vfs_cap_data set_caps(uint64_t capabilities) {
     if (capabilities == 0)
         return cap_data;
 
-    cap_data.magic_etc = VFS_CAP_REVISION | VFS_CAP_FLAGS_EFFECTIVE;
+    cap_data.magic_etc = VFS_CAP_REVISION_2 | VFS_CAP_FLAGS_EFFECTIVE;
     cap_data.data[0].permitted = (uint32_t) capabilities;
     cap_data.data[0].inheritable = 0;
     cap_data.data[1].permitted = (uint32_t) (capabilities >> 32);