where stuff is apparently under /system_ext/apex/...
instead of /system/apex/...
Bug: 277646103
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I947e44af334628d82ca633546f3328319c2bac60
This is a follow-on CL for aosp/2528043
/system/apex/com.android.tethering.inprocess/bin/for-system/clatd
is bind mounted as /apex/com.android.tethering/bin/for-system/clatd
when using inprocess tethering.
Bug: 273821347
Test: `ls -l /apex/com.android.tethering/bin/for-system/clatd` on bertha
Test: Also see aosp/2528043 for how it is tested
Change-Id: Ia20165663e4ff6d9266fe601d25395816792a3f7
This reverts commit 66bfb9adac, and
instead includes a header that has a definition of TEMP_FAILURE_RETRY
for macOS.
Bug: http://b/181852591
Test: N/A
Change-Id: I63ccdcb58a2b2806217e3faedde9ba33936c8189
We don't have any right now. Let's keep it that way.
Also remove a bunch of duplication/cruft in the build file.
Test: treehugger
Change-Id: I406985592c175f45660e87adb05231bce0804893
Now that tune2fs and resize2fs may be dynamic, add linker[64] to
first_stage_ramdisk/system/bin.
Test: boot and examine serial output, ensure tune2fs and resize2fs
can be executed.
Bug: 173425293
Change-Id: I35699b38ddf5004c04ec0adc1b0c54d5d9c92ae6
Added missing partitions (/product and /vendor).
APEXes can be put in /system, /system_ext, /product, and /vendor.
Binaries within "flattened" apexes should be marked as executable.
Bug: 167383491
Bug: 169025459
Test: OVERRIDE_TARGET_FLATTEN_APEX=true m vendorimage with a vendor apex
simg2img $OUT/vendor.img vendor.img
debugfs -R 'ls -l /vendor/apex/com.android.foo/bin' vendor.img
=> check if binaries are executable
Change-Id: I67284166d70c98a2a184b47e7052ade8b9039df9
This directory contains only the su binary which is executable only by
root and shell uids, so need not be accessible to other users.
Test: Device boots
Test: adb shell ls -ld /system/xbin
Change-Id: I4c9daab68b29832ef0ace2dec274687e4496da81
SurfaceFlinger requires CAP_SYS_NICE which is set in
libcutils/fs_config.cpp. This is the old way of setting capabilities
and new the way is to set it directly on surfaceflnger.rc
Test: adb shell /data/nativetest64/SurfaceFlinger_test/SurfaceFlinger_test
Test: adb shell stop surfaceflinger && adb shell start surfaceflinger
Bug: 147271477
Change-Id: I680509a385928a9c929d4fe4857118af219e2b13
Flattened APEXes can be installed in /system_ext.
Especially, GSI have both flattened/unflattened apexes so that it can
run with updatable devices and non-updatable devices as well.
Bug: 145963716
Test: flash GSI on P device and boot
Change-Id: I3a941672446a5353517243a851739a66f4252617
Setting executable bit on system_ext/bin is missing, so add them into
list.
Bug: 144066307
Test: m && check if system_ext/bin/* have execute permission.
Change-Id: I89c9e0d2d54f965ecd058bb9e77ba77b7ed164c1
This change is part of a topic that moves the recovery resources from the
system partition to the vendor partition, if it exists, or the vendor directory
on the system partition otherwise. The recovery resources are moving from the
system image to the vendor partition so that a single system image may be used
with either an A/B or a non-A/B vendor image. The topic removes a delta in the
system image that prevented such reuse in the past.
The recovery resources that are moving are involved with updating the recovery
partition after an update. In a non-A/B configuration, the system boots from
the recovery partition, updates the other partitions (system, vendor, etc.)
Then, the next time the system boots normally, a script updates the recovery
partition (if necessary). This script, the executables it invokes, and the data
files that it uses were previously on the system partition. The resources that
are moving include the following.
* install-recovery.sh
* applypatch
* recovery-resource.dat (if present)
* recovery-from-boot.p (if present)
This change moves the recovery resources to vendor in libcutils/fs_config.cpp
and removes the flash_recovery service from rootdir/init.rc. This service moved
to a vendor init.rc file in bootable/recovery/applypatch.
Bug: 68319577
Test: Ensure that recovery partition is updated correctly.
Change-Id: I492f7989ea8042912e9d0e0eadeaa351affbee13
No one outside of libcutils is using these structs and we don't want
to leak them as they are private.
Test: build
Change-Id: I1c95564a9843c9155a333334008cbff7c7ff1f51
We replaced creating the binary fs_config files with a python script
(/build/make/tools/fs_config/fs_config_generator.py), so there are no
more users of this function, nor do we plan for there to be.
Test: build
Change-Id: I49ec7e3d22c206bc250cbda6f66a4a59e47030e9
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 odm's binary files can't have executable permission.
Add default executable permission in odm/bin and vendor/odm/bin.
Previously partitions that except system, only appeared in
system partition if product haven't separated partition.
After support ODM, vendor/odm should considered.
Bug : 124465978
Test : Check each file's permission.
system/vendor/bin/* -> 0755
system/product/bin/* -> 0755
system/product_services/bin/* -> 0644
system/oem/bin/* -> 0644
vendor/odm/bin/* -> 0755
vendor/product/bin/* -> 0644
vendor/product_services/bin/* -> 0644
Change-Id: I5cee48474fceaf73853b2013d58017bd64953d86
It appears Chase has fixed their app, so we no longer need to keep these
permissions relaxed.
This reverts commit 53842f8a90.
Bug: 119605322
Test: compiles and boots
Change-Id: Iba5e9ecd685eb386997a5e92638b8a1b5943ad4b
When TARGET_FLATTEN_APEX is set to true, the APEXes are flattened
directly under /system/apex/<name>. Among them the runtime APEX carries
binaries such as linker, dex2oat and they need to be configured to be
executable.
Bug: 123684826
Test: Marlin/sailfish boots to the UI
Change-Id: I8ebe9dc4341410ff91ca2cb7cf95e21b0829c008
Also add simpleperf_app_runner in shell utilities.
Bug: 118835348
Test: build and boot.
Test: run simpleperf_app_runner manually.
Change-Id: I538503dabfa8ff192f4b3029206a62613eacdf32
In commit f4fc922f0b, we tightened the
permissions on various bin directories. Please see
https://android-review.googlesource.com/c/platform/system/core/+/822955
for details.
This change causes the Chase banking app to crash. This is because
the Chase app is using inotify_add_watch() on the /system/bin directory
and not checking the return value.
The Android Security model guarantees the immutability of files in
/system/bin, so the inotify watch is unnecessary.
Until the Chase app fixes their bug, we need to relax the permissions on
the /system/bin directory. Conceptually, this is a partial revert of
f4fc922f0b.
Bug: 119605322
Test: compiles
Change-Id: Ic72dd24cb27cff677093963bdfd0ae09bf132e08
Currently, /system/bin, /system/xbin, /product/bin, and /vendor/bin
are 0755, which allows any process to iterate through those
directories and list out the contents. For the vast majority of
processes, this is unnecessary. They only need to know whether a
particular binary exists or doesn't exist, but they don't need to
know the other binaries within those directories.
Allowing this is particularly problematic for SELinux. In particular,
some third party Android applications try to examine every file in
the bin directories, generating SELinux audit noise along the
way. This audit noise makes it harder to see real bugs, and falsely
implies an architectural dependency between the application and random
files in directories like /system/bin.
This change removes the ability to list the contents of the various bin
directories, preventing random probing by such apps. The ability to
execute files, or to probe a specific file by name, remain unchanged.
Addresses SELinux denials similar to the following:
avc: denied { getattr } for comm="Thread-11" path="/system/bin/atrace" dev="dm-0" ino=189 scontext=u:r:untrusted_app_27:s0:c512,c768 tcontext=u:object_r:atrace_exec:s0 tclass=file permissive=0 app=uk.co.santander.santanderUK
avc: denied { getattr } for comm="Binder:26637_2" path="/system/bin/atrace" dev="dm-0" ino=168 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:atrace_exec:s0 tclass=file permissive=0 app=com.tencent.mm
avc: denied { getattr } for comm="Thread-12" path="/system/bin/apexd" dev="dm-0" ino=451 scontext=u:r:untrusted_app_27:s0:c512,c768 tcontext=u:object_r:apexd_exec:s0 tclass=file permissive=1 app=com.grppl.android.shell.CMBlloydsTSB73
Shell access to these directories continues to be allowed, to allow for
host-side CTS tests.
Also adjust the indentation of some clang directives, to make the
presubmit hooks happy.
Test: Device boots and no apparent problems.
Change-Id: Ibe75682fac1983d39f3f479a5850ab5a96f6627d
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
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
This change removes the CAP_SYSLOG file based capability from bootstat,
since the intention is that it should not be accessing the logs in the
long term. In order to avoid bitrot, the fallback code that depends on
CAP_SYSLOG has also been removed.
Bug: 62845925
Test: system/core/bootstat/boot_reason_test.sh
Change-Id: I899be44ef3ac1c4d81072f801d55c928ae09bb15
This change moves logd's capabilities from being file based to being set
by init through ambient capabilities.
Bug: 62845925
Test: sailfish:/ # grep Cap /proc/`pidof logd`/status
CapInh: 0000000000000000
CapPrm: 0000000440000000
CapEff: 0000000440000000
CapBnd: 0000000440000040
CapAmb: 0000000000000000
$ capsh --decode=0x440000040
0x440000040=cap_setgid,cap_audit_control,cap_syslog
Test: liblog-unit-tests, logd-unit-tests, logcat-unit-tests
Change-Id: I28c7c4ad37ad5eafd399aef78c303ce31298a9ef
Normally, the whole configfs is mounted on /config and /config will be
word readable:
sailfish:/ $ ls -ld /config/*
drwxrwx--- 258 system package_info 0 2018-05-08 16:08 /config/sdcardfs
sailfish:/ $ ls -ld /config/
drwxr-xr-x 3 root root 0 1969-12-31 16:00 /config/
On ARC++, we only mount-bind config/sdcardfs, so it is important that
/config is set properly.
It is actually 0500, so system could not see /config/sdcardfs, even if
/config/sdcardfs is set properly:
Although root can, as system uid, we can not reach /config/sdcardfs:
:/ $ ls -ld /config
dr-x------ 3 root root 31 2018-05-02 21:56 /config
:/ $ ls -ld /config/sdcardfs
ls: /config/sdcardfs: Permission denied
With this change, system (and systemservice) is able to reach
/config/sdcardfs:
:/ $ ls -ld /config
dr-xr-xr-x 3 root root 31 2018-05-02 21:56 /config
:/ $ ls -ld /config/sdcardfs
drwxrwx--- 109 system package_info 0 2018-05-08 15:29 /config/sdcardfs
Bug: 63876697
Test: After change, package service is able to create the bindings in
/config/sdcardfs.
Change-Id: I7e9b99d7af2ad001fbb1b95bee35d494e861be78
Signed-off-by: Gwendal Grignou <gwendal@google.com>
Their capability bits are now specified in their associated init .rc
file, which is the proper place for this to be done.
A notice is added to guide developers away from using android_files to
give services Linux capabilities and to guide them away from adding
vendor/ entries.
Bug: 74554159
Test: BT, Wifi, Tethering work on walleye
Merged-In: I13c425d022b4f5c217587cdf601884ef44650ac7
Change-Id: I13c425d022b4f5c217587cdf601884ef44650ac7
(cherry picked from commit b5e5c56401)
Their capability bits are now specified in their associated init .rc
file, which is the proper place for this to be done.
A notice is added to guide developers away from using android_files to
give services Linux capabilities and to guide them away from adding
vendor/ entries.
Bug: 74554159
Test: BT, Wifi, Tethering work on walleye
Change-Id: I13c425d022b4f5c217587cdf601884ef44650ac7
This reverts commit 656b75c77c.
Capability bits are moving from fs_config.cpp to the associated init
scripts for daemons on /vendor.
Bug: 74554159
Test: wifi tethering works on walleye
