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
This CL will enable reading /product/build.prop and add product paths
into ld.config.txt.in.
Bug: 64195575
Test: tested with 'PRODUCT_PRODUCT_PROPERTIES := ro.product.abc=abc' on
sailfish
Change-Id: Ie996def20e25dc1afe0c74af2096af844934b2dc
Finishing a TODO from vendor_init, check SELinux permissions before
setting properties in vendor_init.
Bug: 62875318
Test: N/A
Change-Id: I3cb6abadd2613ae083705cc6b9c970587b6c6b19
Properties right now can take any format, but that makes it hard to
specify an API for these properties as Treble intends to do.
Therefore this change introduces the idea of property types, described below.
1) 'string' this is the default type and allows any property to be set.
2) 'bool' this allows only boolean values (true|false|1|0)
3) 'int' and 'uint' these allow signed and unsigned integer values
respectively.
4) 'double' this allows floating point numbers with double precision.
5) 'size' this allows for strings matching [0-9]+[gkm].
6) 'enum' this allows only a specific set of space deliminated values
to be set, e.g. 'enum allow these strings' only allows one of 'allow',
'these', or 'strings' to be set.
Bug: 70858511
Test: unit tests, test that properties are only set if their type matches
Change-Id: I7a6b00fb43ec630d1f56c9e9a1f1b61d3914f603
Also fallbacks to nonplat_* if it doesn't exists.
Bug: 64240127
Bug: 70279378
Test: boot bullhead and sailfish
Change-Id: I372b42a3c559ae0f9602163699eaef4df148467b
There is a 2s timeout for system property set that currently
uses boot_clock as its clock source. If the system goes to sleep
during a property set, it may erroneously cause the timeout to
be reached as boot_clock increments during sleep. This patch
changes from boot_clock to steady_clock to ignore time spent
asleep when determining this timeout.
bug: 71497234
Test: 1. System service process try to set a system property
with timeout 2s
2. At the same time, the system go into sleep mode more
than 2s
3. System property set will be ok.
Change-Id: I808b9af16974a0f4de60a4ca30ae64d095a13422
Instead of requiring each process to parse the property contexts files
in libc initialization, this change has property_service parse these
files one into a serialized trie, which the property code in libc can
then directly interpret for mapping property names to their associated
SELinux context.
Bug: 36001741
Test: boot bullhead, walleye, run unit tests
Change-Id: If67073d56e800b3ca667fb5322e6b993e7d810f6
Java already restricts properties to only UTF8 valid strings, and
this change makes this restriction also apply to all native code.
Bug: 63177684
Test: new unit tests
Change-Id: I9fa0ecc0da066b0a026db3497c0f0cbf3f5c2d5a
