Explicitly call restorecon_recursive on /metadata/apex
On some devices we see a weird in which /metadata/apex will have a wrong
selinux label. This will effectively prevent such devices from getting
any apex updates. Since we haven't figured out a root cause for this
bug, it's safer to explicitly call restorecon on /metadata/apex to make
sure it's correct.
This change shouldn't affect a normal boot flow, since /metadata/apex
will already have a correct label and restorecon_recursive will be a
no-op.
Test: rm -Rf /metadata/apex && \
mkdir /metadata/apex &&
mkdir /metadata/apex/sessions
Bug: 149317789
Merged-In: I971ffe35c93bb79d9e71106c24515ec0ee70333a
Change-Id: I971ffe35c93bb79d9e71106c24515ec0ee70333a
(cherry picked from commit cf7b6bad55b3c41d8289852488eb4496a4524ba5)
diff --git a/rootdir/init.rc b/rootdir/init.rc
index 226bcf4..fb6f1be 100644
--- a/rootdir/init.rc
+++ b/rootdir/init.rc
@@ -520,6 +520,13 @@
mkdir /metadata/apex 0700 root system
mkdir /metadata/apex/sessions 0700 root system
+ # On some devices we see a weird behaviour in which /metadata/apex doesn't
+ # have a correct label. To workaround this bug, explicitly call restorecon
+ # on /metadata/apex. For most of the boot sequences /metadata/apex will
+ # already have a correct selinux label, meaning that this call will be a
+ # no-op.
+ restorecon_recursive /metadata/apex
+
on late-fs
# Ensure that tracefs has the correct permissions.
# This does not work correctly if it is called in post-fs.