Support legacy apexdata labels
This partly reverts fa10a14fac28f9c407b4ff800972f9cef75fcf35. There we
removed individual labels for various apexdata labels, replacing them
with apex_system_server_data_file.
Unfortunately that doesn't handle upgrade scenarios well, e.g. when
updating system but keeping the old vendor sepolicy. The directories
keep their old labels, and vold_prepare_subdirs is unable to relabel
them as there is no policy to allow it to.
So we bring back the legacy labels, in private not public, and add the
rules needed to ensure system_server and vold_prepare_subdirs have the
access they need. All the other access needed is obtained via the
apex_data_file_type attribute.
Bug: 217581286
Test: Reset labels using chcon, reboot, directories are relabeled, no denials
Change-Id: If696882450f2634e382f217dab8f9f3882bff03f
diff --git a/private/system_server.te b/private/system_server.te
index 1e79932..1cf7ac4 100644
--- a/private/system_server.te
+++ b/private/system_server.te
@@ -1329,6 +1329,19 @@
# These are modules where the code runs in system_server, so we need full access.
allow system_server apex_system_server_data_file:dir create_dir_perms;
allow system_server apex_system_server_data_file:file create_file_perms;
+# Legacy labels that we still need to support (b/217581286)
+allow system_server {
+ apex_appsearch_data_file
+ apex_permission_data_file
+ apex_scheduling_data_file
+ apex_wifi_data_file
+}:dir create_dir_perms;
+allow system_server {
+ apex_appsearch_data_file
+ apex_permission_data_file
+ apex_scheduling_data_file
+ apex_wifi_data_file
+}:file create_file_perms;
# Allow PasswordSlotManager rw access to /metadata/password_slots, so GSIs and the host image can
# communicate which slots are available for use.