Allows for easy override of fuse-bpf for testing without a rebuild
Test: Set this property with ro.fuse.bpf.enabled both true and false
Make sure ro.fuse.bpf.is_running is expected result
Bug: 219958836
Change-Id: I589511ea5cda76db1d55bdc2124fb546907d8acd
s_running flag signals to tests whether fuse-bpf is running
Test: Builds, runs, ro.fuse.bpf.is_running is correct, fuse-bpf works
Bug: 202785178
Change-Id: I2b967567092da2fab90e44c44ff2e51b372b85ed
DM_DEV_CREATE no longer creates sysfs nodes as of Linux kernel 5.15. It
is now necessary to DM_TABLE_LOAD as well.
Bug: 259328366
Test: userdata mounts
Change-Id: I0f88afdf95a97d44eb365e4302bbfdc7c28c0bcb
With the way the FUSE mount point are currently setup for emulated
volumes, there can be multiple paths that serve the same files on the
lower filesystem; eg
* /mnt/user/0/emulated/0/Android
* /mnt/user/10/emulated/0/Android
both refer to the same file on the lower filesystem:
* /data/media/0/Android
this is normally not a problem, because cross-user file access is not
allowed, and so the FUSE daemon won't serve files for other users.
With clone profiles this is no longer true however, as their volumes
are accessible by each other.
So, it can happen that an app running in clone profile 10 accesses
"/mnt/user/10/emulated/0/Android", which would be served by the FUSE
daemon for the user 10 filesystem.
At the same time, an app running in the owner profile 0 accesses
"mnt/user/0/emulated/0/Android", which would be served by the FUSE
daemon for the user 0 filesystem.
This can cause page cache inconsistencies, because multiple FUSE daemons
can be running on top of the same entries in the lower filesystem.
To prevent this, use bind mounts to make sure that cross-profile
accesses actually end up in the FUSE daemon to which the volume
belongs: "/mnt/user/10/emulated/0" is bind-mounted to
"/mnt/user/0/emulated/0", and vice-versa.
Bug: 228271997
Test: manual
Change-Id: Iefcbc813670628b329a1a5d408b6126b84991e09
retrieveKey can fail in load_all_de_keys if a user
is partially removed, i.e. cases where
fscrypt_destroy_user_key() got interrupted. So just
ignore the failure, else could reboot into recovery.
Test: pm create-user foo
pm remove-user 10
adb reboot && check device not enter recovery
Signed-off-by: liulvping <liulvping@xiaomi.com>
Change-Id: Iba9d53a0833524d00e65d0427ab03002c5d8d509
When running on kernel without FUSE, fs::directory_iterator
throws exception since /sys/fs/fuse/connections is missing.
This patch uses non-throwing fs::directory_iterator
and adds explicit error check.
Test: vold doesn't fail with FUSE disabled
Signed-off-by: Oleg Lyovin <ovlevin@sberdevices.ru>
Change-Id: I51b68363edf75033fcec3ce5623f419d5a68c991
As a small optimization and code simplification, stop reading and
writing the "stretching" file alongside each stored key. vold never
does key stretching anymore.
There was one special case in the code where if the stretching file
existed and contained "nopassword", then the secret was ignored.
However, this didn't seem to be of any use, especially since it didn't
cause Keystore to be used, so it did *not* allow a key stored with no
secret to be read if a secret was unexpectedly provided.
Bug: 232452368
Bug: 251131631
Bug: 251147505
Change-Id: I5a7cbba7492526e51c451f222b9413d9fae6bce5
Storage keys that are encrypted by the user's synthetic password don't
need to be securely deletable by vold, since secure deletion is already
implemented at a higher level: the synthetic password protectors managed
by LockSettingsService. Therefore, remove the use of the secdiscardable
file by vold in this case to improve performance.
Bug: 232452368
Bug: 251131631
Bug: 251147505
Change-Id: I847d6cd3b289dbeb1ca2760d6e261a78c179cad0
The legacy method for metadata encryption on adoptable storage failed
when the size of the block device isn't a multiple of the crypto sector size.
Update the size of dm-crypt device according to sector size
before construct dm_target.
Bug: 248582018
Change-Id: I5c78889bdfedca7f7b0704500fc313d7a48d5a3b
Signed-off-by: Hongyu Jin <hongyu.jin@unisoc.com>
am skip reason: Merged-In I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6 with SHA-1 2d30b890d2 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2186984
Change-Id: I0f16d59d0fd19f3e1c31f1e1b34f7745a1854ded
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6 with SHA-1 2d30b890d2 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2186984
Change-Id: Ic61f28f1c336a049d02664b12a4d6c95c98323b0
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6 with SHA-1 2d30b890d2 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2186984
Change-Id: I66e62f75632b9997f411989952dea65f6cbb6c9f
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6 with SHA-1 2d30b890d2 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2186984
Change-Id: Ia960d269e55ca3a616f92e35d78eb775b0f42089
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6 with SHA-1 2d30b890d2 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2186984
Change-Id: I8081ab864aaf5d222f02a0ac3cf8557b058a959c
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6 with SHA-1 2d30b890d2 is already in history
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2186984
Change-Id: I22c2be9483000fbf4b7c44190828b7ee96bc7ef4
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
