Partial revert of "init: if vendor_init can read a property, let it be
a trigger too" (b35f827c97).
We made a mistake when we allowed vendor init to action on any vendor
or odm property, since when a new SELinux label is created for a
vendor property, vendor_init does not automatically get read
permissions for it.
Recently, we tried to use read permissions instead of the built-in
list in init, but that broke due to the above mistaken. Since we have
already launched with these permissions as is, we must restore them.
Bug: 118457755
Test: no denials for vendor init actionable properties on crosshatch
Change-Id: I7a9a560c9a54a177c6b83d28309e2f288f05d400
There is a list of 'stable_properties' that vendor_init can use as
property triggers for Treble property compliance. This list came about
since init parses init scripts before all partitions are mounted and
therefore before all property context files are available, such that
init cannot use the normal SELinux mechanisms for determining if a
given property is vendor_init readable.
Currently though, we require all partitions that would contain
property context files to be mounted during first stage mount, so we
can use the normal SELinux mechanisms here, so this change deprecates
the stable_properties list and moves init to use SELinux to determine
if a property can be a trigger.
Bug: 71814576
Test: vendor_init fails to use non-readable properties as a trigger
Test: vendor_init successfully uses readable properties as a trigger
Change-Id: I6a914e8c212a3418cbf4a8a07215056aad2e0162
Create a host side parser for init such that init rc files can be
verified for syntax correctness before being used on the device.
Bug: 36970783
Test: run the parser on init files on host
Change-Id: I7e8772e278ebaff727057308596ebacf28b6fdda
