vold creates some directories for storing encryption keys if they don't
already exist, potentially including parent directories:
/metadata/vold/metadata_encryption
/data/misc/vold/volume_keys/$volume_uuid
/data/misc_de/$user/vold/volume_keys/$volume_uuid
/data/misc_ce/$user/vold/volume_keys/$volume_uuid
Currently fs_mkdirs() is used for this. However, fs_mkdirs() doesn't
include the fsync()s of the parent directories that are needed to ensure
that the new directories are persisted to disk right away -- which is
important for encryption keys.
Add a utility function MkdirsSync() which does what is needed, and make
the appropriate places call it.
Test: Booted and checked log for "Created directory" message.
Also ran 'atest vold_tests' to run the new unit test.
Change-Id: Ie9917b616433080139b8db3fd6877203ee6faf77
When an FBE or metadata encryption key is created, it's important that
it be persisted to disk right away; otherwise the device may fail to
boot after an unclean shutdown. storeKey() has the needed fsync()s.
However, storeKeyAtomically() doesn't, as it doesn't fsync() the parent
directory of key_path after it renames tmp_path to it.
Two callers do fsync() the parent directory themselves, but others
don't. E.g., the metadata encryption key doesn't get properly synced.
Therefore, add the needed fsync() to storeKeyAtomically() so that it
gets done for everyone.
Also remove the now-unneeded fsync()s from the two callers that did it
themselves.
Change-Id: I342ebd94f0a3d2bf3a7a443c35b6bda0f12e1ab2
Added SPDX-license-identifier-Apache-2.0 to:
Android.bp
bench/inodeop_bench/Android.bp
tests/Android.bp
Bug: 68860345
Bug: 151177513
Bug: 151953481
Test: m all
Exempt-From-Owner-Approval: janitorial work
Change-Id: I91823c7097d7bee39a363a0c0cc30de13e4d7539
Has to be done before SystemConfig initialization to set correct
Incremental version feature.
Bug: 180010901
Test: atest PackageManagerShellCommandTest PackageManagerShellCommandIncrementalTest IncrementalServiceTest PackageManagerServiceTest ChecksumsTest
Change-Id: I262d1f06aecb481f37bf82005c85fed02c476510
With this change, vold exposes an API that may be used to bind key
storage encryption keys to a given seed value. The seed value passed to
vold must be consistent across reboots, or key storage keys will not be
derived consistently. The seed is expected to be set very early in boot,
prior to the use of any key storage encryption keys.
This feature is intended to be used for embedded applications such as
in autos, where the seed may be provided by some other component of the
system. In such systems, there is a default user that is automatically
signed in without a PIN or other credentials. By binding the file
encryption to a platform-provided seed, the default user's data gains
additional protection against removal of the Android embedded device
from the integrated system.
Bug: 157501579
Test: Set seed at startup via init.rc. Seed changes fail as expected.
Change-Id: I9b048ec5e045b84c45883724ace2356d4ef6244d
This reverts commit a71323ec0e.
Reason for revert: b/177926359 - note that this is a Google testing infrastructure issue, and no issue with this patch. Partners can keep using this patch. It will be resubmitted in a few weeks.
Change-Id: Ia13279ac1aafa2e4425c4527aeadd5d0fadbc2e4
This reverts commit 8ed81fd9ca.
Reason for revert: Let me try one last time more carefully. According to https://googleplex-android-review.git.corp.google.com/q/%2522customize+stubvolume%2522 - this CL will flow to aosp branches (without vendor images) and 2 branches with vendor images. I have submitted the vendor CL for both branches now (ag/13366009 and ag/13371672). This should not break anything now.
Change-Id: I69aacceabfb70053387a3c156b49e06be65fe6e4
So we can ensure Android/ dir is created,
otherwise EnsureDirExists may return false if Android/ doesn't exist
Bug: 177281374
Test: Able to boot without errors
Change-Id: I02e816b60530ac9d3d3b978a7c9028d2c0e34bad
This reverts commit 0cf77b025d.
Reason for revert: The requird libarcvolume has been submitted to master (ag/13366009)
Change-Id: I86fada53aad2ec5faa497a9bcbce5435c35d040e
This new method will be used in new sm command.
Tests can use this so data and obb dirs are unmounted, and won't
be killed when volume is unmounted.
Bug: 148049767
Test: New sm command able to unmount app's data and obb dirs
Change-Id: Ifbc661ca510e996abd4b7ce1fb195aaa7afc37ad
The new flag is used to indicate that a stub volume (external storage
volume shared with Chrome OS) is visible to Android apps.
Bug: 123377807
Bug: 142684760
Bug: 132796154
Test: Check logcat logs for StorageManagerService.mount() when the
Test: visibility setting of a removable device is toggled in Chrome OS.
Test: Confirm that the visibility setting is properly set.
Test: (Tested in R)
Change-Id: Ica69110d5667837a72a5c8693ff3bccc0f09a82d
This allow ARC to customize StubVolume implementation in vendor
partition.
Bug: 132796154
Test: Customize the implementation of StubVolume and check on device.
Ignore-AOSP-First: Will cherry-pick to AOSP.
Change-Id: I626a7ed4113b6132bb456b3258ee4a93b4f8a72e
Prefix all HIDL HAL types with the letter H.
Also make the invocation more generic so that we can use
the AIDL implementation in the future.
Test: TH
Bug: 177470478
Change-Id: Iee0af9727c48c532315203c138a4996a08fcaa34
Since Android R, the FUSE prop is always on and FUSE-off is no longer
supported
Test: m
Bug: 160159282
Merged-In: Ic4414b850511fe3b4fc6df3f8b736d21335db820
Change-Id: I5a7643f9ca2f37cd7f264331df76b42df31988d5
This directory is used as a root for external storage on adopted storage
devices. It needs to be writable by processes holding the AID_MEDIA_RW
GID permission; in particular, it should be writable by the FUSE daemon.
On devices with sdcardfs, this was ensured automatically, because
sdcardfs presented a view of this directory that was writable, that we
could use for the FUSE daemon. But on devices without sdcardfs, the FUSE
daemon sees the raw filesystem and its permissions. This also means that
files created by the FUSE daemon will have their uid/gid set to the uid
of the FUSE daemon; to ensure these files stay writable to other system
applications that have AID_MEDIA_RW, use a default ACL to make sure the
gid stays AID_MEDIA_RW.
In particular, this fixes an issue with app cloning, where we want the
FUSE daemon of user 0 to be able to access the files of the app clone
user, and vice versa.
Bug: 154057120
Test: inspect uid/gid of /data/media/0 and contents
Change-Id: Ib718b8362df84754ee3cac33865bca3c12df2e3a
This directory is used as a root for external storage on adopted storage
devices. It needs to be writable by processes holding the AID_MEDIA_RW
GID permission; in particular, it should be writable by the FUSE daemon.
On devices with sdcardfs, this was ensured automatically, because
sdcardfs presented a view of this directory that was writable, that we
could use for the FUSE daemon. But on devices without sdcardfs, the FUSE
daemon sees the raw filesystem and its permissions. This also means that
files created by the FUSE daemon will have their uid/gid set to the uid
of the FUSE daemon; to ensure these files stay writable to other system
applications that have AID_MEDIA_RW, use a default ACL to make sure the
gid stays AID_MEDIA_RW.
In particular, this fixes an issue with app cloning, where we want the
FUSE daemon of user 0 to be able to access the files of the app clone
user, and vice versa.
Bug: 154057120
Test: inspect uid/gid of /data/media/0 and contents
Change-Id: I6dfae41f9cb6a8283978b2667b02708a000f07c0
