Everything in FsCrypt.cpp seems to run under VolumeManager::mCryptLock,
except for fscrypt_destroy_volume_keys() which uses mLock instead.
This was sort of okay because fscrypt_destroy_volume_keys() didn't
operate on any in-memory data structures. However, that is going to be
changed. Therefore, rework VoldNativeService::forgetPartition() to call
fscrypt_destroy_volume_keys() under mCryptLock.
Test: see I7f11a135d8550618cd96013f834cebd54be5ef84
Change-Id: Ia27a61faf2fdd546cdbddb2a3985c7c6696f6aa6
Merged-In: Ia27a61faf2fdd546cdbddb2a3985c7c6696f6aa6
(cherry picked from commit ce86e24d23)
StorageStatsManager.getTotalBytes currently takes the size of /data and
rounds up to known probable sizes to guess the size of internal storage.
This is not always correct.
Instead, find the device /data is on and get the size of that device.
This should give a more accurate answer.
Bug: 295358118
Test: vdc volume getStorageSize returns storage size
Change-Id: I907892041b1ce2cd72092a9877ac34c12bf3f254
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
Mounting encrypted OBB files has never worked reliably across devices,
partly due to its reliance on Twofish encryption support in the kernel.
This is because Twofish support (CONFIG_CRYPTO_TWOFISH) has never been
required or even recommended for Android. It has never been enabled in
GKI, but even before GKI it wasn't required or recommended. Moreover,
this is now the only Android feature that still uses dm-crypt
(CONFIG_DM_CRYPT), and some devices don't have that enabled either.
Therefore, it appears that this feature is unused. That's perhaps not
surprising, considering that the documentation for OBBs
(https://developer.android.com/google/play/expansion-files) says that
they are deprecated, and also it explains OBBs as being app files that
are opaque to the platform; the ability of the platform to mount OBBs
that happen to be in a particular format is never mentioned. That means
that OBB mounting is probably rarely used even with unencrypted OBBs.
Finally, the usefulness of OBBs having their own encryption layer (in
addition to what the platform already provides via FBE) is not clear
either, especially with such an unusual choice of cipher.
To avoid the confusion that is being caused by having the broken code
for mounting encrypted OBBs still sitting around, let's remove it.
Test: atest StorageManagerTest # on Cuttlefish
Test: atest StorageManagerIntegrationTest # on Cuttlefish
Bug: 216475849
Change-Id: Iaef32cce90f95ea745ba2b143f89e66f533f3479
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
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
As storage is not mounted in system server, we use vold
to check if storage app data and obb directories exist instead.
We add a method in vold so it only creates app data and obb dirs
if dirs do not exist to speed up app starting time.
Bug: 160336374
Test: Data and obb directories are created when a new app is started
Change-Id: I1bd784d9c9e05463f71433fc782ac4e0c831cbf1
This can be done through binder as well as vdc, using 'vdc volume
abort_fuse'.
Bug: 153411204
Test: adb shell vdc volume abort_fuse
Change-Id: I93e46dc1cd361729cc1162c63520cf73152ea409
Test: Manually verified ownership of /storage/emulated/0/Android/data on cf_x86_phone-userdebug after enabling feature
Bug: 151455752
Change-Id: I75a1e3b769476e56094e41d82e7f8e1a72827ded
Also, use the pids provided by system server to remount all existing
processes, so we don't need to do the heavy and unreliable scanning in
/proc anymore.
Bug: 149548518
Test: atest AdoptableHostTest
Change-Id: Ifb5b79a3bc5438f36e0d61ec8aec96bdbc60ca13
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)
- 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
StubVolume is a volume type for ARC++ external storage. Named StubVolume
because it is managed from outside Android (not through Android kernel).
Previously, StubVolume is a diskless volume. However, as mentioned in
jsharkey@ email, a disk is needed for StubVolume to hold "kInternal"
(external storage type that is "external" from Android perspective,
but is "internal" to the device. For example shared directory from
ChromeOS to Android) and "kIndexable" (whether or not a disk should be
indexed by MediaStore).
The addition of disk means we could expose the createStubVolume API to
add a disk flags, which is also introduced in this CL.
Both kInternal and kIndexable will be introduced in separate CL.
Bug: 132796154
Test: Mount/unmount ARC++ removable device in ChromeOS.
Change-Id: I8b77fa1cf50ab38a2892272154dafdb78f079378
When we're asked to create an app directory, find the corresponding
volume, and use the raw path of that volume to create the directory.
This ensures this will continue working on devices that don't have
sdcardfs.
Bug: 146419093
Test: manual test on cuttlefish
Change-Id: I91d735c1adbcca171e5af73aca0abd7ef396d0b7
Public and private volumes can be discovered before user 0 is up and
running; when using FUSE however, we can't mount these disks yet,
because we depend on the user to become unlocked before we can start the
FUSE daemon (which is the MediaProvider application process). So besides
waiting for any secure keyguard to be dismissed, also wait for user 0 to
be started.
Bug: 146419093
Test: Boot cuttlefish with a fake public volume; is available after
repeated boots.
Change-Id: I06fe4d336d1baec3a49886c3cf12d844a1d0eb26
vold historically offerred functionality to create directories on behalf
of others. This functionality was purely used to create app-specific
data/obb/media dirs. Make this more explicit by renaming the method to
indicate this.
Additionally, in the past, we never needed to care about the UID set on
these directories, because sdcardfs would take care of that for us
automatically. But with sdcardfs going away, we need to make sure the
UID of the app-specific directories is set correctly. Allow the caller
to pass this in as an argument.
Bug: 146419093
Test: atest FuseDaemonHostTest
Change-Id: Ibeb5fdc91b40d53583bc0960ee11c4d640549c34
We want started users to be an ordered set; eg user 0 should always go
first. This is because volumes for users other than 0 depend on user 0
coming up first, because the volume for user 0 is the one mounting
sdcardfs.
Bug: 13789012
Test: atest AdoptableHostTest
Change-Id: Ic9119f0a24bd261e5362019836ac240b90c681c0
Up until now, the FUSE mount logic has made two assumptions:
1. The primary external volume is an emulated volume on /data/media
2. Only the primary user is running, as user zero
These assumptions are fixed by the following changes
creating an EmulatedVolume per Android user and changing the
VolumeBase id format to append the user to the id, so
s/emulated/emulated-0/. This allows us mount separate volumes per user
Some additional refactorings to re-use/clean up code.
Test: adb shell sm set-virtual-disk and partition disk operations work
even after setting up a work profile
Bug: 135341433
Change-Id: Ifabaa12368e5a591fbcdce4ee71c83ff35fdac6b
Apps that are already installed on the device before isolated_storage
feature is enabled will be granted MOUNT_EXTERNAL_LEGACY mode. In this
mode, /mnt/runtime/write will be mounted at /storage giving them same
level of access as in P.
A new mount directory /mnt/runtime/full is also created which will be
used for mounting at /storage for apps started with MOUNT_EXTERNAL_FULL
mode. This will allow apps with WRITE_MEDIA_STORAGE permission to
read/write anywhere on the secondary devices without needing to bypass
sdcardfs.
Bug: 121277410
Test: manual
Test: atest android.appsecurity.cts.ExternalStorageHostTest
Change-Id: Icc1ff9da35545692daedef7173d7c89290dd2766
We make some of the C++ member functions 'const', to reflect how
they (don't) affect the state of the class.
Test: TreeHugger
Change-Id: Iec1c2801bfe721e2741406ed1ac0ef95662840a6
When an app is started, it's mountmode is dependent on
OP_REQUEST_INSTALL_PACKAGES. If user changes the appop grant of an app,
we need to update the mounts of any processes running in that app.
Bug: 121099965
Test: atest android.appsecurity.cts.ExternalStorageHostTest#testExternalStorageObbGifts
Change-Id: I87fee492891d33ccc9fc9e2548114f67d90cc759
New external storage mount mode for installers so
that they can access obb dirs of all apps.
Bug: 111789719
Test: atest android.appsecurity.cts#testExternalStorageObbGifts
Change-Id: Iab112f0273806f8f812f14d6691bbe71dff42d83
Previously, AppFuse is mounted in system_server's mount namespace. This
CL moves the mount location to vold namespace.
Relanding this since it fails to be merged on ag/5521004 (blocked by
Presubmit, seems to be caused by temporary state) - this one now
passes presubmit without any changes.
Bug: 110379912
Test: testOpenProxyFileDescriptor passes
Change-Id: Id93c26d5a98842c78f27850c83e15df619cec1ab
Previously, AppFuse is mounted in system_server's mount namespace. This
CL moves the mount location to vold namespace.
Bug: 110379912
Test: testOpenProxyFileDescriptor passes
Change-Id: Id93c26d5a98842c78f27850c83e15df619cec1ab
StubVolume is a Volume that is maintained by external party such as the
ChromeOS processes in ARC++.
Bug: 110380403
Test: Tested on ARC++
Change-Id: I3198bd7283d5f60a524da3707dea7385ffec599d
Instead of maintaining local copy of all appIds and sandboxIds,
StorageManagerService will just get required packages info
from PackageManagerService when an user starts and passes it
to vold.
Bug: 117988901
Test: manual
Change-Id: Idab274529e843784c8804929e920c3af63032690
- Also update vold to create sandboxes for secondary storage devices.
- Since bind mounts are created in the process specific namespaces, we
don't need /mnt/storage anymore which we were using it to prevent
some bind mounts from propagating onto /mnt/runtime/write.
- Create bind mounts for {media,obb} dirs similar to data dir in
per process namespace.
- Also fix a bug where we are not passing correct packages to vold when
a new user starts.
Bug: 111890351
Test: manual
Change-Id: I7849efc4fbf3c654606fa30de7ab2de0236d766f
Apply clang-format to fix the remaining files not fixed by
change I23cde3f0bbcac13bef555d13514e922c79d5ad48
Test: Format-only changes; treehugger suffices.
Change-Id: I1bfd5c8d68d298596875d5edae26cdfe27c03489
Create a new slave bind mount at /mnt/storage and use this for
creating package sandboxes. This will help prevent package
specific data directories from getting duplicated and also make
handling bind mounts for packages with sharedUserIds easier.
Bug: 111890351
Test: manual
Change-Id: I0f590cc99a379d93f6db85bf56e8d274e3ea7488
Vold is updated to create package specific sandboxes for primary
volume and mount them at
"/mnt/user/<user-id>/package/<package-name>/<primary-label>".
This will later be mounted at /storage when a new process starts.
Bug: 111890351
Test: Manually verified that a package has access to "/sdcard" and
"/storage/emulated/0", both of which are just the package specific
sandboxes and the package doesn't have access to other sandboxes
and can't see other package names.
Change-Id: I72dc8ae9eb2260a298159c5de18387dad2f9de48
Bug: 111890351
Test: n/a
Change-Id: Ia24f15112f9a4ee4994688ff8fedf786cbf479b7
Exempt-From-Owner-Approval: This was approved as part of http://ag/4494673
