This is a behavior change and may have unintended consequences,
especially in Java, where failed property sets create exceptions.
Therefore, we only provide this new behavior to devices launching > Q.
Bug: 137070994
Test: build
Change-Id: If0b44aedc5c887ea6ea16dd3ec551ac2bf793cef
This CL only draws boundaries between userspace and full reboots, and
adds some functionality that will be required for userspace reboot:
* Whenever device is shutting down is now controlled in reboot.cpp,
since during userspace reboot this state can change.
* Now it's also possible to restart handling of control messages inside
property service. In case of userspace reboot, init will restart it
after stopping post-data services.
* New userspace-reboot-requested trigger is added similar to shutdown
one for full reboot.
Test: adb reboot
Test: adb reboot userspace
Bug: 135984674
Change-Id: Id55a53ba781d2b90ce40449037b6d8d47e72c476
Commit I27dd391fc06a3c78e88a65c7931c84de1699f157 makes property_service
no longer load selinux property_contexts by function
selinux_android_prop_context_handle.
So we should load property_contexts from /system_ext as well in
property_service.cpp.
Bug: 137712473
Bug: 141871131
Test: `adb shell getprop -Z` to check system_ext_property_contexts is loaded
Change-Id: I49c5c725784c0d598062ae356be6226446f4942a
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
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
Host init verifier already checks that the names and number of
arguments for builtins are correct, but it can check more. This
change ensures that property expansions are well formed, and that
arguments that can be parsed on the host are correct. For example it
checks that UIDs and GIDs exist, that numerical values can be parsed,
and that rlimit strings are correct.
Test: build
Change-Id: Ied8882498a88a9f8324db6b8d1020aeeccc8177b
It's better to pass the error message to the caller to determine how
best to print the error.
Test: build
Change-Id: Id8857c459df2f26c031650166609608d20e4d051
clang-tidy hinted that some of this code wasn't right. Looking
deeper, there is really not much related to file and socket
descriptors, except that they're published in similar ways to the
environment. All of the abstraction into a 'Descriptor' class takes
us further away from specifying what we really mean.
This removes that abstraction, adds stricter checks and better errors
for parsing init scripts, reports sockets and files that are unable to
be acquired before exec, and updates the README.md for the passcred
option.
Test: build, logd (uses files and sockets) works
Change-Id: I59e611e95c85bdbefa779ef69b32b9dd4ee203e2
android-base:
* Add NOLINT for expanding namespace std for std::string* ostream
overload
libdm:
* Fix missing parentesis around macro parameters
init:
* Fix missing CLOEXEC usage and add NOLINT for the intended
usages.
* Fix missing parentesis around macro parameters
* Fix erase() / remove_if() idiom
* Correctly specific unsigned char when intended
* 'namespace flags' should be signed, since 'flags' it signed for
clone()
* Add clear to property restore vector<string> to empty after move
* Explicit comparison against 0 for strcmp
Test: build
Change-Id: I8c31dafda2c43ebc5aa50124cbbd6e23ed2c4101
It's been a long standing problem that init calls fs_mgr functions
synchronously and therefore stops handling properties, which causes
deadlocks if either fs_mgr, or vdc, or vold attempt to set
properties.
Previous work, b/21904461, shows that there is a large performance
penalty for adding any amount of locking to properties, so moving
property service into its own thread generically is not a viable
option. However, we can be sure that init is not setting properties
while the fs_mgr functions are running, so we can poll the property
socket in a thread while we call these functions.
The other alternative would have been to separate the fs_mgr functions
into smaller pieces and revisit the main init loop between each
piece. Unfortunately, this would be difficult, since
fs_mgr_mount_all() calls out to different processes via logwrapper,
which synchronously polls on a logging FD from the child, among other
complexities that would make this strategy much more difficult than it
would be worth.
Bug: 21904461
Test: device boots, including when setting property in
fs_mgr_mount_all()
Change-Id: Ib0b7123024035884f9d90f9b489c1e2f5a2e1707
This change is to support importing property file with its path
variations.
By substitute its filename with another, it can be used to handle
runtime varying filename within single binary.
Here's an example of usage in property defined file.
import /odm/build_${ro.boot.product.hardware.sku}.prop
Bug: 132592551
Test: boot a device and checks above example import statement in
"/odm/build.prop" loading expanded filename correctly
Change-Id: If3fdcf620a5d717e0930b1e4e58261bc8f79ec24
In device root directory, we have the following symlinks:
- /odm/app -> /vendor/odm/app
- /odm/bin -> /vendor/odm/bin
- /odm/etc -> /vendor/odm/etc
...
This allows the Generic System Image (GSI) to be used on both devices:
1) Has a physical odm partition, where those symlink will be hidden
when /odm is used as the mount point
2) Has no physical odm partition and fallback to /vendor/odm/.
We can't just have the symlink /odm -> /vendor/odm, because the former
devices won't have /vendor/odm directory, which leads to mount failure
when the mount point /odm is resolved to /vendor/odm.
The existing /vendor/odm/build.prop won't be loaded in the latter
devices, because there is no symlink
- /odm/build.prop -> /vendor/odm/build.prop.
Note that init blocks reading through direct symlinks (O_NOFOLLOW) so
the above symlink won't work either. This CL moves the odm build.prop
to /odm/etc/build.prop for init to load it (symlinks in earlier
components of the path will still be followed by O_NOFOLLOW).
Bug: 132128501
Test: boot a device and checks /odm/etc/build.prop is loaded
Change-Id: I0733c277baa67c549bb45599abb70aba13fbdbcf
Merged-In: I0733c277baa67c549bb45599abb70aba13fbdbcf
In the future, property service may run in its own thread or process,
which means that PropertyChildReap() needs to be refactored to not run
as part of the init signal handler.
The new method spawns a new thread that handles the queue of paths
that require restorecon. It then communicates back to property service
via android::base::SetProperty(). Property service distinguishes the
thread from other callers of SetProperty() by checking the pid in the
credentials for the socket connection, thus avoiding dependencies on
the rest of init.
The new method also drops the genericness, since restorecon is the
only function that we should ever need to run asynchronously
Test: async restorecon works, including with queued requests
Change-Id: I2ca00459969e77b1820776dac23d0a0d974e330b
Though unlikely, it is possible for getpeercon() to fail. This change
adds code to handle this case gracefully.
Bug: 130209483
Test: boots, properties are set
Change-Id: I3b3fb76b2312a5cbc87c0da2a044be3ddf8aa400
The setup of SelinuxAuditCallback() was happening after property files
are loaded, and now that these property files can trigger audits, the
audit messages did not contain all of the correct information. This
change moves the setup of SelinuxAuditCallback() to immediately before
the property area is initialized, to ensure that this can not happen
again.
Bug: 130979265
Test: audits work early
Change-Id: I9eb43269317c74e041626ee7b2bb7fea49250e09
In previous implementation, userdebug sepoilcy and property files are
loaded from the system.img. This CL changes this to:
- first-stage init copies userdebug files from ramdisk to /debug_ramisk/*
- second-stage init loads files from /debug_ramdisk/*.
Note: same as before, the above can only be triggered, if the device
is UNLOCKED
With this, we don't have to put userdebug related files into the USER
system.img.
Bug: 126493225
Test: boot device with a ramdisk with /force_debuggable, checks related
files are loaded
Change-Id: I63f5f846e82ba78427062bf7615c26173878d8f3
The purpose of having fine grain read/write control over the property
space is to help ensure the confidentiality of data stored in
properties. Leaking property values into the dmesg buffer on errors
exposes the value outside of the access control rules specified by
policy.
(arguably this is also true for the property name, not just the value.
However, property names are exposed in other places now, so the
incentive to fix this is lower. It would also take away a valuable
debugging tool.)
Test: compiles
Change-Id: I4a0634b8b5e4fd2edf718eaf7343940df627366d
When init found "/force_debuggable" in the first-stage ramdisk, it will
do the following if the device is unlocked:
1. load /system/etc/adb_debug.prop (with ro.debuggable=1)
2 .load userdebug_plat_sepolicy.cil instead of original plat_sepolicy.cil from
/system/etc/selinux/.
This make it possible to run VTS on a USER build GSI, by using a special
ramdisk containing "/force_debuggable".
Bug: 126493225
Test: unlock a USER build device, check 'adb root' can work
Change-Id: I9b4317bac1ce92f2c0baa67c83d4b12deba62c92
"ro." properties do not make sense for prop files, especially with the
way that the system/product and vendor/odm partitions are meant to
override each other. To fix this, we ignore the fact that "ro."
properties are "write once" when first loading in property files.
We then adjust the order of property file loading, such that we read
partitions from least to most specific, reading in order: system,
vendor, odm, product, product_services.
Bug: 122864654
Test: ro. properties can override when reading build props with
appropriate permissions
Test: ro. properties do not override when lacking permissions to
be set by a given partition
Change-Id: Ib9a5f77e95d9df647cdde7a5c937bb3425c066fa
Commit I27dd391fc06a3c78e88a65c7931c84de1699f157 make property_service no longer
load selinux property_contexts by function selinux_android_prop_context_handle,
So we should config /odm and /product property_contexts loading path in
property_service.cpp but not in libselinux.
Test: property_service can load property_contexts in /odm and /product
Change-Id: Ifa94b87180c4867ecbe8dea347ad02bb37958043
If not present, ro.product.[brand|device|manufacturer|model|name] and
ro.build.fingerprint will be resolved during init from
partition-specific properties.
Test: booted system image, verified properties
Test: booted recovery image, verified properties
Bug: 120123525
Change-Id: I7fe2793a7d9eb65645d92ceb408f1f050acf9a81
It looks like this code is dead currently. From history, this was
meant to be used as a way to check that the recovery image is what was
expected during runtime, but that effort never completed, and we have
full verification of the recovery image when booting into recovery
anyway.
The code is functionally dead as is too, since /recovery doesn't
actually exist in any fstab, since recovery is either mounted as a
ramdisk during recovery or not mounted during normal boot.
Test: boot
Change-Id: I48cd324ef0d5a163db2df2648f6042174b83f10e
*/build.prop files are now loaded much earlier than before; from 'on
post-fs' to the time when the property service is started which is
before init starts the action loop.
This ensures that all processes that are launched by init have a
consistent view of system properties. Previously, the processes that
started before 'on post-fs' were initially with the small number of
sysprops loaded from */default.prop and then suddenly get additional
sysprops from */build.prop while they are executing.
Bug: 122714998
Test: device boots
Change-Id: Ic07528421dfbe8d4f43673cea41175d33cfbf298
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
Attempting to reduce the number of different spellings we have for
"product services" partition in the codebase.
Bug: 112431447
Test: m
Change-Id: I1a87d7e040a8b1f91f973ac7d90d6360b5b54f71
Merged-In: I1a87d7e040a8b1f91f973ac7d90d6360b5b54f71
We're moving past a world where static executables are needed,
including watchdogd, so treat this like any other executable and place
it in /system/bin.
Bug: 73660730
Test: watchdogd still runs
Change-Id: I1f7508fd55dce6e9ee72a6ab7a085011a76c0053
This CL is largely and adaptation of
Ie996def20e25dc1afe0c74af2096af844934b2dc
Bug: 80741439
Test: Successfully built product-services.img with one module in it, and
flashed on device. Also successfully built image with
/system/product-services and no dedicated /product-services partition.
Change-Id: I1046dfe19bf874da929c9131b76a1f85422fbb80
Merged-In: I1046dfe19bf874da929c9131b76a1f85422fbb80
Currently, permissions for ctl. property apply to each action verb, so
if a domain has permissions for controlling service 'foo', then it can
start, stop, and restart foo.
This change implements finer grainer permissions such that permission
can be given to strictly start a given service, but not stop or
restart it. This new permission scheme is mandatory for the new
control functions, sigstop_on, sigstop_off, interface_start,
interface_stop, interface_restart.
Bug: 78511553
Test: see appropriate successes and failures based on permissions
Merged-In: I6ce915ae39954a67eb6fe1795a93cf715c352ae4
Change-Id: I6ce915ae39954a67eb6fe1795a93cf715c352ae4
(cherry picked from commit 1debdcf1cf)
It's currently not clear that the error no indicating the
failure to invoke the library function. This change introduces
logs at the failing of socket connect, that could be clearly
get the true reason.
Test: Set system property with failed, and socket recv errno
log will show
Change-Id: I36bf66988811f953e679d1c5a468de0bf1ab0a05
Signed-off-by: Jinguang Dong <dongjinguang@huawei.com>
GetIntProperty() isn't used after
Ied46e9346b4ca7931aa4dcf1c9dbc11de0e12d93, so it can be removed.
Test: build
Change-Id: I5736f553db1a615d51b8fe3cbf9b4aee89451076
This commit uses vendor sepolicy file version (defined in
`/vendor/etc/selinux/plat_sepolicy_vers.txt`) to determine whether the
source context should be set as `u:r:vendor_init:s0`.
Before this commit, the criterion was `ro.vndk.version` >= 28. However,
the check in `property_service.cpp` will always be true because
`ro.vndk.version` hasn't been loaded from `/vendor/default.prop`.
Furthermore, under some circumstances, `ro.vndk.version` may be
different from `plat_sepolicy_vers.txt` (e.g. O-MR1 vendor does not
define `ro.vndk.version`).
Bug: 78605339 # high-level bug to combine O-MR1 and P GSI
Bug: 79135481 # the usage of `ro.vndk.version` in init
Test: vts-tradefed run vts -m VtsTrebleVintfTest # tetheroffload
Change-Id: Ied46e9346b4ca7931aa4dcf1c9dbc11de0e12d93
Do not restrict vendor_init restrictions on vendor images that were
built before P, as they will not have the correct permissions.
Bug: 77732028
Test: test new devices and see vendor_init still works
Change-Id: I636a07b54fbfb248e1d1a68a8f3c4d047fd5a9e9
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
Currently we only report why a property set call has failed but drop
the context of what was trying to set the property. This change
adds information about why a property was trying to be set when it
fails.
It also unifies property_set() within init to go through the same
HandlePropertySet() function as normal processes do, removing unneeded
special cases.
Test: boot bullhead
Test: attempt to set invalid properties and see better error messages
Change-Id: I5cd3a40086fd3b226e9c8a5e3a84cb3b31399c0d
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
It's currently not clear that init stops processes due to being sent a
control message nor who sent that message.
Bug: 73343913
Test: send control messages and see the logs
Change-Id: I9e9eff2001e649814107ea961b3b747a1f6da598
Tom Cherry