Previously, we assumed that TriggerShutdown() should never be called
from vendor_init and used property service as a back up in case it
ever did. We have since then found out that vendor_init may indeed
call TriggerShutdown() and we want to make it just as strict as it is
in init, wherein it will immediately start the shutdown sequence
without executing any further commands.
Test: init unit tests, trigger shuttdown from init and vendor_init
Change-Id: I1f44dae801a28269eb8127879a8b7d6adff6f353
It's been a long standing issue that init cannot respond to property
set messages when it is running a builtin command. This is
particularly problematic when the commands involve IPC to vold or
other daemons, as it prevents them from being able to set properties.
This change has init run property service in a thread, which
eliminates the above issue.
This change may also serve as a starting block to running property
service in an entirely different process to better isolate init from
handling property requests.
Reland: during reboot, init stops processing property_changed messages
from property service, since it will not act on these anyway. This
had an unexpected effect of causing future property_set calls to block
indefinitely, since the buffer between init and property_service was
filling up and the send() call from property_service would then
block. This change has init tell property_service to stop sending it
property_changed messages once reboot begins.
Test: CF boots, walleye boots, properties are set appropriately
Change-Id: I26902708e8be788caa6dbcf4b6d2968d90962785
It's been a long standing issue that init cannot respond to property
set messages when it is running a builtin command. This is
particularly problematic when the commands involve IPC to vold or
other daemons, as it prevents them from being able to set properties.
This change has init run property service in a thread, which
eliminates the above issue.
This change may also serve as a starting block to running property
service in an entirely different process to better isolate init from
handling property requests.
Test: CF boots, walleye boots, properties are set appropriately
Change-Id: I13b8bf240c9fcb1d2d5890a8be2f0ef74efd4adf
It's been a long standing issue that init cannot respond to property
set messages when it is running a builtin command. This is
particularly problematic when the commands involve IPC to vold or
other daemons, as it prevents them from being able to set properties.
This change has init run property service in a thread, which
eliminates the above issue.
This change may also serve as a starting block to running property
service in an entirely different process to better isolate init from
handling property requests.
Test: CF boots, walleye boots, properties are set appropriately
Change-Id: Id9534a5916abb2f7d2a49cda54e33c1b69c50c2f
Finishing a TODO from vendor_init, check SELinux permissions before
setting properties in vendor_init.
Bug: 62875318
Test: N/A
Change-Id: I3cb6abadd2613ae083705cc6b9c970587b6c6b19
Currently init expands properties in arguments only when those
commands are run in a subcontext. This creates a hole where
properties that should not be accessible from a given subcontext of
init can be accessed when running a command in the main init
executable (for example `start`).
This change creates a callback in subcontext init that simply expands
and returns arguments back to the main init process, to ensure that
only those properties that a subcontext can access get expanded.
Bug: 62875318
Test: boot bullhead, new unit tests
Change-Id: I2850009e70da877c08e4cc83350c727b0ea98796
One of the major aspects of treble is the compartmentalization of system
and vendor components, however init leaves a huge gap here, as vendor
init scripts run in the same context as system init scripts and thus can
access and modify the same properties, files, etc as the system can.
This change is meant to close that gap. It forks a separate 'subcontext'
init that runs in a different SELinux context with permissions that match
what vendors should have access to. Commands get sent over a socket to
this 'subcontext' init that then runs them in this SELinux context and
returns the result.
Note that not all commands run in the subcontext; some commands such as
those dealing with services only make sense in the context of the main
init process.
Bug: 62875318
Test: init unit tests, boot bullhead, boot sailfish
Change-Id: Idf4a4ebf98842d27b8627f901f961ab9eb412aee
