change 'for-system' owner from root to clat
See https://b.corp.google.com/issues/402962730#comment27
for explanation how clat uid not having access to this
directory causes selinux denials, but basically the dynamic
linker tries to call realpath on /proc/self/exe, which fails
because it's post setuid/gid and thus running as clat/clat,
not as uid=root or gid=system which have access.
(note that the 'w' bits don't really matter since this is
embedded in an apex, and thus readonly filesystem anyway)
Bug: 402962730
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Iaf620e33d9211c9bc0c017543bb1be2f43520a51
diff --git a/Tethering/apex/canned_fs_config b/Tethering/apex/canned_fs_config
index 1f5fcfa..edc5515 100644
--- a/Tethering/apex/canned_fs_config
+++ b/Tethering/apex/canned_fs_config
@@ -1,3 +1,3 @@
-/bin/for-system 0 1000 0750
+/bin/for-system 1029 1000 0750
/bin/for-system/clatd 1029 1029 06755
/bin/netbpfload 0 0 0750
diff --git a/service/jni/com_android_server_connectivity_ClatCoordinator.cpp b/service/jni/com_android_server_connectivity_ClatCoordinator.cpp
index c0082bb..622fba8 100644
--- a/service/jni/com_android_server_connectivity_ClatCoordinator.cpp
+++ b/service/jni/com_android_server_connectivity_ClatCoordinator.cpp
@@ -104,7 +104,7 @@
// First verify the clatd directory and binary,
// since this is built into the apex file system image,
// failures here are 99% likely to be build problems.
- V(kClatdDir, S_IFDIR|0750, ROOT, SYSTEM, "system_file", DIR);
+ V(kClatdDir, S_IFDIR|0750, CLAT, SYSTEM, "system_file", DIR);
V(kClatdBin, S_IFREG|S_ISUID|S_ISGID|0755, CLAT, CLAT, "clatd_exec", BIN);
// Move on to verifying that the bpf programs and maps are as expected.