Commit graph

7 commits

Author SHA1 Message Date
Tom Cherry
14c2472734 init: degeneralize subcontext init into only vendor_init
This code is more generic than it needs to be and one of the side
effects is that an extra init process is forked for odm_init, despite
it having the same context as vendor_init.  I don't think anything is
going to change regarding that soon, so this change stops forking that
extra process to save its memory and simplifies the code overall.

Bug: 141164879
Test: init still uses vendor_init for vendor_scripts
Test: init unit tests
Test: init only has one subcontext process
Change-Id: I0d224455604a681711e32f89fb20132378f69060
2019-09-18 14:02:14 -07:00
Tom Cherry
d52a5b3c10 init: simplify keyword_map
I've heard that keyword_map is too complex, in particular the tuple
and the pair in BuiltinFunctionMap, so this change removes a lot of
that complexity and, more importantly, better documents how all of
this works.

Test: boot, init unit tests

Change-Id: I74e5f9de7f2ec524cb6127bb9da2956b5f307f56
2019-07-23 14:39:38 -07:00
Tom Cherry
bbcbc2ffb3 init: replace Result<Success> with Result<void>
Now that Result<T> is actually expected<T, ...>, and the expected
proposal states expected<void, ...> as the way to indicate an expected
object that returns either successfully with no object or an error,
let's move init's Result<Success> to the preferred Result<void>.

Bug: 132145659
Test: boot, init unit tests
Change-Id: Ib2f98396d8e6e274f95a496fcdfd8341f77585ee
2019-06-10 12:39:18 -07:00
Tom Cherry
9949ec5f56 init: replace Result<> with expected<>
Android-base has an implementation of the future std::expected<>.
This provides the same baseline functionality as Result<>, so use it
instead of our own version.

Bug: 132145659
Test: boot, init unit tests
Change-Id: I11e61bcb5719b262a6420483ed51a762826a9e23
2019-05-22 15:23:01 -07:00
Tom Cherry
d987264625 init: add [[nodiscard]] to Result
It's better to either check these results or explicitly ignore them.
Only a few callers weren't already doing this, so it's relatively
trivial to enforce.

Test: build
Change-Id: I44cdc342e46128f66cac914aaa0b9b4559cacd8c
2018-10-11 10:39:33 -07: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
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