Previously every directory on external storage had project ID quota
inheritance enabled; this means that if any new file/directory is
created under such a directory, it will inherit the project ID from the
parent. We use a default project ID of 1000 for generic directories, and
application-specific project IDs for app-specific directories.
MediaProvider is responsible for updating the quota type in the generic
directories, as it scans all files there. However, there is a problem
with this approach: if you move a file to a directory with project ID
inheritance set, and the project ID of that file differs from the
project ID of the dir, that results in an EXDEV error, and requires a
copy instead. For example, if /sdcard/DCIM/test.jpg has a project ID of
1003 (for images), and you try to move it to /sdcard/Pictures/test.jpg,
that would require a copy, because the project ID of /sdcard/Pictures is
1000.
While this is not a very common scenario, it's still better to avoid it.
Luckily we can - since MediaProvider anyway scans all files, it will set
the project ID on individual files correctly - there's no need to
inherit them.
We then only need to inherit quota in application-specific directories,
since in those directories the app can create files itself, and those
need to be tagged correctly.
This change enables that, by removing quota inheritance setting from the
top-level directory, and instead doing it for app-specific directories
instead.
Bug: 151078664
Test: atest StorageHostTest
atest com.android.tests.fused.host.FuseDaemonHostTest#testRenameAndReplaceFile
Change-Id: I38a057ec61cb627e39a3ff7ac58c7218dc251bdc
During userspace reboot /data might be unmounted & remounted, meaning
that CE keys stored in fs-level keyring will be lost. In order to be
able to restore them, when installing new key to fs-level keyring, it's
also added to session-level keyring with type "fscrypt-provisioning".
Then when init_user0 is called during userspace reboot, vold will try to
load CE keys from the session-level keyring back into fs-level keyring
for all the users that were unlocked before the reboot.
If for any user vold fails to install the key, init_user0 will fail and
fallback to hard reboot will be triggered.
Test: set a pin pattern
Test: adb shell setprop sys.init.userdata_remount.force_umount 1
Test: adb shell svc power reboot userspace
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 143970043
Change-Id: I37603dc136c7ededc7b0381e4d730cb0ffd912b4
am skip reason: Change-Id I279f087b1b7aded40c5a62281154851ce970ba70 with SHA-1 48aa90cd6b is in history
Change-Id: I9eb2f1872efa09a914d77404e4ae675cc106f59d
fs_mgr may put other dm devices on top of the raw disk, such as for
checkpointing, and it hands metadata encryption the uppermost device in
vdc. That's what should be encrypted, not the raw disk.
Bug: 150354860
Test: Treehugger
Merged-In: I279f087b1b7aded40c5a62281154851ce970ba70
Change-Id: I279f087b1b7aded40c5a62281154851ce970ba70
am skip reason: Change-Id I919f9e31a9d2d745b297a7ab99b399aa9b293b39 with SHA-1 3cf3233bac is in history
Change-Id: I22164c5f84bf5ab19a8586d2000cbb98a28e33c0
am skip reason: Change-Id I153caa1d7c373b3c906a34f1184c681e52854a9d with SHA-1 1eaea5a6a2 is in history
Change-Id: Ic498847cfe85ac0e45b33d221f6fdb69321f673d
During userspace reboot /data might be unmounted, which means that if
device supports filesystem keyring, DE keys will be lost and are needed
to be re-installed.
Test: adb shell setprop sys.init.userdata_remount.force_umount 1
Test: adb shell svc power reboot userspace
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 143970043
Change-Id: I153caa1d7c373b3c906a34f1184c681e52854a9d
Merged-In: I153caa1d7c373b3c906a34f1184c681e52854a9d
(cherry picked from commit 1eaea5a6a2)
FDE device has shut down and restart the framework.
But restart is not triggered due to umount fail.
umount /data fail with "device is busy"
It is because bind mount /data/data to /data/user/0
We need umount /data/user/0 before umount /data
Bug: 148004718
Test: Flash GSI and check boot with FDE and FBE device.
Change-Id: I919f9e31a9d2d745b297a7ab99b399aa9b293b39
Merged-In: I919f9e31a9d2d745b297a7ab99b399aa9b293b39
(cherry picked from commit 3cf3233bac)
FDE device has shut down and restart the framework.
But restart is not triggered due to umount fail.
umount /data fail with "device is busy"
It is because bind mount /data/data to /data/user/0
We need umount /data/user/0 before umount /data
Bug: 148004718
Test: Flash GSI and check boot with FDE and FBE device.
Change-Id: I919f9e31a9d2d745b297a7ab99b399aa9b293b39
fs_mgr may put other dm devices on top of the raw disk, such as for
checkpointing, and it hands metadata encryption the uppermost device in
vdc. That's what should be encrypted, not the raw disk.
Bug: 150354860
Test: Treehugger
Change-Id: I279f087b1b7aded40c5a62281154851ce970ba70
We should mount Android/data also, not only Android/obb.
Test: After flag is enabled, AdoptableHostTest still pass.
Bug: 148049767
Bug: 150584566
Change-Id: I26dc3756aa5843b85565495e9c2698130113f49a
Merged-In: I26dc3756aa5843b85565495e9c2698130113f49a
(cherry picked from commit d88e090098)
During userspace reboot /data might be unmounted, which means that if
device supports filesystem keyring, DE keys will be lost and are needed
to be re-installed.
Test: adb shell setprop sys.init.userdata_remount.force_umount 1
Test: adb shell svc power reboot userspace
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 143970043
Change-Id: I153caa1d7c373b3c906a34f1184c681e52854a9d
am skip reason: Change-Id I98549c8614c9152d5d45e2f1f33f2f3c31a9bbbf with SHA-1 4fcb707ecd is in history
Change-Id: I333576d11d8782d4b379403459d7cb5b870a9866
AIDL generates optional<T> for nullable T types for C++, which is more
efficient and idomatic and easy to use.
Bug: 144773267
Test: build/flash/boot
Merged-In: I98549c8614c9152d5d45e2f1f33f2f3c31a9bbbf
Change-Id: I98549c8614c9152d5d45e2f1f33f2f3c31a9bbbf
(cherry picked from commit 3ce0ee5363)
Exempt-From-Owner-Approval: CP from master
AIDL generates optional<T> for nullable T types for C++, which is more
efficient and idomatic and easy to use.
Bug: 144773267
Test: build/flash/boot
Merged-In: I98549c8614c9152d5d45e2f1f33f2f3c31a9bbbf
Change-Id: I98549c8614c9152d5d45e2f1f33f2f3c31a9bbbf
(cherry picked from commit 0568fd287cfc0affc8e985f21da3793cdda286a3)
Making HEH the default was always a mistake and a giant foot-gun.
Let's make life easier for people by making the default depend on
first_api_level, so it's automatically set up right for new devices
without breaking old ones. Also use v2 fscrypt keys instead of v1 post
Q.
Bug: 147107322
Test: Various Cuttlefish configurations
Change-Id: I5432bdfd6fec6ed34e7f9ab7cdd32cdeb2a03472
- Remove bind mounting Android/ code as we want to bind mount obb dir
for each process instead.
- Set property "vold.vold.fuse_running_users" as an array of user id
for which fuse is ready to use.
- After fuse is ready for a user, fork a background process in vold
to bind mount all direct boot apps for that user so its direct boot
apps obb dir will be mounted to lower fs for imporoved performance.
Bug: 148049767
Bug: 137890172
Test: After flag is enabled, AdoptableHostTest still pass.
Change-Id: I90079fbeed1c91f9780ca71e37b0012884680b7c
This can be used to fixup application directories in case they have been
created by some other entity besides vold; the main use case for this
API right now is OBB directories, which can be created by installers
outside of vold; on devices without sdcardfs, such directories and the
files contained therein are not setup correctly. This API will make sure
everything is setup the way it needs to be setup.
Bug: 146419093
Test: inspect OBB dir after install
Change-Id: I2e35b7ac2992dbb21cc950e53651ffc07cfca907
