| dc375869abb56a0ef8ee1299443866da1e76abb6 |
|
28-Feb-2018 |
Tom Cherry <tomcherry@google.com> |
Restrict setting platform properties from vendor .prop files
We should only allow vendor-init-settable properties to be set from
.prop files on /vendor and /odm.
Bug: 73905119
Test: test on walleye that disallowed properties are rejected
Change-Id: I2a5d244fdc71060ddda3e3d87442e831e6b97831
/system/core/init/subcontext.h
|
| 618d3102c9aa7d6a6d0e60cc0175ad77319cb27b |
|
19-Jan-2018 |
Tom Cherry <tomcherry@google.com> |
Move all of init to libinit
I'd be not doing this for a while since some of this code doesn't
compile on host and libinit previously did. But after realizing
the property_service.cpp (libinit) references symbols in init.cpp
(init) and seeing a new linker error crop up due to that, it's time to
make the fix.
My only hold out previously was that libinit compiled on host bionic
and some of init (builtins.cpp, etc) do not, however given that we
don't actually have host bionic support or host bionic init tests,
that isn't a good reason. We can and should mock out the libraries
that aren't available with host bionic when ready.
Test: build, unit tests, boot
Change-Id: Ie49362ddb637924efc272540a4f32b693643fcdc
/system/core/init/subcontext.h
|
| c49719fc5d2cf3817f6997ce40fc2dac7d411efa |
|
10-Jan-2018 |
Tom Cherry <tomcherry@google.com> |
init: always expand args in subcontext
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
/system/core/init/subcontext.h
|
| e6d37cdbf98247f2d9dfd574644fa342de8655bc |
|
19-Oct-2017 |
Tom Cherry <tomcherry@google.com> |
init: clean up subcontext_test
subcontext_test had been failing due to setexeccon() failing to
transition to vendor_init context. This is a good thing as nothing
other than init should be able to transition into this context.
I don't want to add code to skip the setexeccon() call only for the
tests, so I instead call setexeccon() with the return value of
getcon(). This works however only for root, so these tests are
skipped for non-root.
Test: init unit tests
Change-Id: I8a415599e0ec5506511202f7f5018c0e5265837d
/system/core/init/subcontext.h
|
| 5d7b55bc69614d4db1423453aa1fd13c1f25a3cf |
|
18-Oct-2017 |
Tom Cherry <tomcherry@google.com> |
init: add extra std::move
This is meant to be copy-and-move, but I forgot the move.
Test: build
Change-Id: I755ad0d99624dc0ae419ad9ed3ae6d0e017b27c5
/system/core/init/subcontext.h
|
| cb0f9bbc855097e0c8248643015b837255fd569a |
|
13-Sep-2017 |
Tom Cherry <tomcherry@google.com> |
init: run vendor commands in a separate SELinux context
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
/system/core/init/subcontext.h
|