Commit graph

7 commits

Author SHA1 Message Date
Luis Hector Chavez
92c49bcb30 init: Cleanly shut down subcontext processes
This change adds an explicit cleanup for the subcontext processes and
avoids them from respawning, which causes a bunch of LOG(FATAL)s when
the system is going down.

Bug: 80425914
Test: kill -TERM $INIT_PID, no crashes for subcontext inits

Change-Id: I135191d959c1dd921b102af316b24d2bc161d6c9
2018-07-27 11:19:44 -07:00
Tom Cherry
dc375869ab 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
2018-03-01 11:17:07 -08:00
Tom Cherry
618d3102c9 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
2018-01-19 14:25:48 -08:00
Tom Cherry
c49719fc5d 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
2018-01-12 10:35:26 -08:00
Tom Cherry
e6d37cdbf9 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
2017-10-19 16:24:56 -07:00
Tom Cherry
5d7b55bc69 init: add extra std::move
This is meant to be copy-and-move, but I forgot the move.

Test: build
Change-Id: I755ad0d99624dc0ae419ad9ed3ae6d0e017b27c5
2017-10-18 14:52:33 -07:00
Tom Cherry
cb0f9bbc85 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
2017-09-29 13:06:26 -07:00