When a volume is ejected from a user but not removed from the device
and mounted again by calling StorageManager#mount, the volume is
mounted for the user from which it was last ejected. This causes the
path of the mounted volume to be inaccessible to the current user.
Whenever StorageManager#mount is called, check if the
VolumeInfo#mountUserId is same as the current userId maintained by
StorageManagerService, if it is not, change the mountUserId for the
Volume to the current userId known to StorageManagerService if it
is not the primary volume and the volume is visible.
This change also fixes a bug where the volumes are unmounted for the
wrong user which causes StorageSessionController go out of sync
which would cause errors during mounting the volumes again as it
maintains sessions per user. The bug also caused volume event
broadcasts to be sent to wrong user handles. To solve the issue
add an extra paramter in IVoldListener#onVolumeStateChanged for userId
which will update the copy which is used for informing
StorageSessionController and also for sending broadcasts.
Test: Perform the following steps:
1. Format SD Card as portable storage in system user.
2. Eject the SD Card from Storage Settings.
3. Switch to a non-system user
4. Mount the SD Card again.
5. Check that the Storage Summary is shown correctly instead
of 0B out of 0B.
Also, checked from the logs the volume state broadcasts are sent to
the correct user handles.
Change-Id: I60b8954cdaee4a54ea6a6299fe5ddda2006faf1c
https://r.android.com/2620458 is removing the write mode bit from the
top-level user directories on internal storage, in order to make the DAC
consistent with the SELinux policy.
This commit makes the corresponding change to adoptable storage.
Bug: 285239971
Test: sm set-virtual-disk true; sm partition disk:7,392 private
Change-Id: I17dfbe10909b34c2046a4d5b4ffd7764d5ae083b
This reverts commit 564f6c649a.
Reason for revert: Un-backporting.
Note: This is not a direct revert. We should keep the minor refactoring
in PublicVolume.cpp; no point making the code worse.
Test: Revert.
Change-Id: Ic03ed25ad15a2da974921542a20cd27224347f68
This CR, when paired with a functional NTFS implementation and the
corresponding SEPolicy updates, will allow NTFS USB drives to be mounted
on Android.
Bug: 254407246
Test: Extensive testing with an ADT-4 and NTFS USB drives.
Merged-In: If4197c4c588866c611cd6ba3483707d3cb0e0cf8
Change-Id: If4197c4c588866c611cd6ba3483707d3cb0e0cf8
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
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
persist.sys.fuse.bpf.enable and ro.fuse.bpf.enabled are both used to
decide if FUSE-BPF must be enabled or not.
- ro.fuse.bpf.enabled is a read-only property that is set in the device
makefile and would allow dogfooding devices to turn the feature
on/off.
- persist.sys.fuse.bpf.enable is a system property that overrides
ro.fuse.bpf.enabled and can only be set manually during the
development to simplify the testing of FUSE-BPF, mostly to compare if
those tests that are failing with FUSE-BPF were failing also without
the feature.
Bug: 202785178
Test: adb logcat | grep "FuseDaemon" | grep BPF
Ignore-AOSP-First: FUSE-BPF is not available in AOSP
Signed-off-by: Alessio Balsini <balsini@google.com>
Change-Id: I23f9d27172907f6c72c73bea22e4a7e0ac643888
We want to store sdk data on the same volume as app data. Since sdk data
is stored in misc_ce and misc_de directory, we need to ensure they exist
on adopted storage mounted at /mnt/expand/<volume-uuid>.
This CL creates `/mnt/expand/<volume-uuid>/misc_{ce,de}` directories
when disk is mouted and then when user storage is prepared, the sdk root
directory is created.
By having these directories, we can now move the sdk data to other
volume when app data is moved.
Bug: b/222034645
Test: atest SdkSandboxStorageHostTest (see ag/17120883)
Ignore-AOSP-First: End to end test added which exists in internal branch
only. Will cherry-pick this CL to aosp standalone once it is safely
merged to internal branch.
Change-Id: I0e73d9ce105abec4b77c378cde58aa7365258f01
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
[Description]
When we plug out external device, and
vold didn’t finish unmount process properly
which will lead folder under /mnt/media_rw not removed.
This will cause mount fail
when we plug in same device again
due to operation not permitted when create the folder again.
Test:
1.AC on/off pass
2.issue not seen
Bug: 194163828
Change-Id: Ia7c6c23ca55ce71cd6c3d3fa15bed5bc5199acfd
StubVolumes are managed from outside Android (e.g. from Chrome OS). So,
their disk recreation on vold reset events should also be handled from
outside by 1) listening to reset events, and 2) calling
createStubVolume() for existing StubVolumes on reset events.
Bug: 175281783
Test: m
Test: (Tested in R) Manually induce a vold reset event, and confirm that
Test: 1) vold does not crash, and 2) existing volumes are successfully
Test: mounted again (by calling createStubVolume() for StubVolumes).
Change-Id: I4628eabf809037a547aeef43faedf4dfa57529a6
FUSE BPF aims at achieving comparable performance to bind-mounts, with
the flexibility of FUSE.
Disable data and obb bind-mounts in favor of the FUSE filesystem if the
system implements the feature.
Bug: 202785178
Test: mount | grep obb
Signed-off-by: Alessio Balsini <balsini@google.com>
Change-Id: Ia8b289b84542125831a857b559bb6f93afbee494
IVold.MOUNT_FLAG_VISIBLE is split into MOUNT_FLAG_VISIBLE_FOR_READ and
MOUNT_FLAG_VISIBLE_FOR_WRITE.
Accordingly, VolumeBase::MountFlags::kVisible is split into
kVisibleForRead and kVisibleForWrite.
Bug: 206019156
Test: m
Change-Id: Ia55673400d9f713f221650e1335a46ba11f6f027
Merged-In: Ia55673400d9f713f221650e1335a46ba11f6f027
Otherwise, when system removes user's volume, it will hang
as there are mounts (obb and data mounts) still remain mounted in system.
Bug: 187122943
Test: atest UserLifecycleTests#managedProfileUnlock_stopped, it's not blocked anymore
Change-Id: Ic37985f98e6cbfe4fa38b981d3332c4dfc40c5b8
Originally it kills all the apps with obb and data mounted.
Due to recent changes, all apps will have obb and data dirs mounted
in default root namespace. Hence all apps will be killed by
by KillProcessesWithMounts().
To fix this, we also check if the dir is mounted as tmpfs,
as the default namespace one is bind mounted to lowerfs,
which app data isolation is mounted as tmpfs, so we only
kill the process that have obb dir mounted as tmpfs.
Bug: 148049767
Test: Able to boot without warnings
Change-Id: I5f862ad6f64f5df739b68ea7c9815352bae3be5c
Merged-In: I45d9a63ed47cbc27aebb63357a43f51ad62275db
So shell / root will always access to them directly not via fuse.
And zygote will be unmount these directories to prevent them being
abused for leaking app visibility.
Also, /mnt/androidwritable is not very useful now as it's the same as
/mnt/installer, but we should make shell / root to access /mnt/androidwritable
later and /mnt/installer should only access obb but not data dir.
Bug: 182997439
Test: Able to boot without errors
Test: df on /sdcard/Android/data shows it's no on fuse.
Change-Id: I2ad10b1e80c135f637d37ddf502ee010f89f4946
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
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
We previously only set +F for /data/media, but adopted storage needs
this as well. Instead we add support for adding attrs to PrepareDir.
Bug: 163453310
Test: sm set-virtual-disk true
follow UI setup and confirm +F on /mnt/expand/*/media
Change-Id: I08f13b57a4de3538e88b38eb95b0ac115a5a5ce8
Merged-In: I08f13b57a4de3538e88b38eb95b0ac115a5a5ce8
The name "pre_gki_level" is causing some confusion because not all
devices launching with Android R are subject to the GKI requirement.
(See b/161563110#comment11.) E.g., devices that use a 4.14-based kernel
are exempt from GKI. However, the encryption requirements still apply.
Just use __ANDROID_API_Q__ directly instead.
No change in behavior.
Change-Id: Id02ae1140845ac1ae7cf78be4e57fe34da028abf
By default FUSE filesystems have a max_ratio of 1%, meaning only 1% of
dirty pages on the system can belong to a FUSE filesystem before we
start writing back pages (and throttling, if writeback can't keep up).
This limit is useful for untrusted filesystems, but in our case, we
trust the FUSE filesystem. Since FUSE writes result in writes to the
lower filesystem, FUSE should take at most 50%. Let's start with
changing max_ratio to 40%, to avoid needless throttling.
Bug: 159254170
Bug: 159770752
Test: inspect /sys/class/bdi manually after boot
Change-Id: I467e3770fc4afba0a08fa480c0b86aa054c8b875
Sometimes, during early boot, a public volume may be created before
the user is unlocked and the mount may fail. This mount failure does
not revert the lower fs mounts (sdcardfs and vfat). Subsequent
mount attempts will then fail because we'd attempt to mount vfat on
already mounted /mnt/media_rw/<volname>
Bug: 158489548
Test: Resilient to an artificial sleep in
StorageManagerService#completeUnlockUser to
delay user unlock longer than public volume mount
Change-Id: I9a1574596434a2eb6b2553c0c9220c2118c7e4fd
For fuse read ahead can be configured by writing a value to the
/sys/class/bdi/{MAJOR}:{MINOR}/read_ahead_kb file.
There are several different ways of getting {MAJOR}:{MINOR} values of
the filesystem:
* Look at st_dev of stat("/mnt/user/0/emulated").
* Parse /proc/self/mountinfo.
Stat'ing approach is used since it's easier to implement.
Bug: 157982297
Test: atest vold_tests
Test: adb shell cat /proc/self/mountinfo to get MAJOR:MINOR
Test: adb shell cat /sys/class/bdi/{MAJOR}:{MINOR}/read_ahead_kb
Test: created public volume, checked it's read_ahead_kb is also 256
Change-Id: Id0c149c4af1ceabf3afc33b4100563a512b38316
This allows devices that have sdcardfs enabled in the kernel to not use
it. When external_storage.sdcardfs.enabled=0, sdcardfs will not be
mounted. This is treated as default true to not affect upgrading
devices. It does not use the old ro.sys.sdcardfs as that has been
repurposed over time and no longer can be relied on to turn off
sdcardfs. This is included within emulated_storage.mk
Bug: 155222498
Test: mount|grep "type sdcardfs" should find nothing after boot complete
if external_storage.sdcardfs.enabled=0
Change-Id: I23d75fb1225aeabbcb1a035ad62fd042b6b3c7b5
When the vold core decides if a device is SD or USB, it checks for MMC
or virtio, however when the filesystem type is decided, it does not
check for virtio, only MMC. This causes virtio SD cards to be formatted
with ext4 unconditionally.
This fix is independently correct, but it incidentally gets adopted
storage working on cuttlefish (and Android Emulator) because f2fs can
support fscrypt and casefolding at the same time; ext4 currently cannot.
Bug: 156286088
Change-Id: I0b41670d5f76b2506dad437917c2276f8e0aaccf
Merged-In: I0b41670d5f76b2506dad437917c2276f8e0aaccf
When the vold core decides if a device is SD or USB, it checks for MMC
or virtio, however when the filesystem type is decided, it does not
check for virtio, only MMC. This causes virtio SD cards to be formatted
with ext4 unconditionally.
This fix is independently correct, but it incidentally gets adopted
storage working on cuttlefish (and Android Emulator) because f2fs can
support fscrypt and casefolding at the same time; ext4 currently cannot.
Bug: 156286088
Change-Id: I0b41670d5f76b2506dad437917c2276f8e0aaccf
The Android Emulator isn't the only virtual device the virtio-block
detection code is useful for, and those platforms might not set any
discriminating properties to indicate that they are virtual.
Rework the virtio-block major detection to use /proc/devices instead
of hardcoding the assumption that any virtual platform can have
virtio-block at any experimental major; the new code permits only the
exact experimental major assigned to virtio-block.
The new code runs everywhere, but it will only run once and could be
expanded later to detect dynamic or experimental majors.
Bug: 156286088
Change-Id: Ieae805d08fddd0124a397636f04d99194a9ef7e5
Merged-In: Ieae805d08fddd0124a397636f04d99194a9ef7e5
The Android Emulator isn't the only virtual device the virtio-block
detection code is useful for, and those platforms might not set any
discriminating properties to indicate that they are virtual.
Rework the virtio-block major detection to use /proc/devices instead
of hardcoding the assumption that any virtual platform can have
virtio-block at any experimental major; the new code permits only the
exact experimental major assigned to virtio-block.
The new code runs everywhere, but it will only run once and could be
expanded later to detect dynamic or experimental majors.
Bug: 156286088
Change-Id: Ieae805d08fddd0124a397636f04d99194a9ef7e5
When we're mounting a private volume, we create stacked emulated volumes
on top of it. Due to the ordering there, we would broadcast the emulated
volumes being created *before* the "mounted" status update. This in turn
could cause us to try and mount these emulated volumes before the
underlying private volume is really mounted. This is problematic in
particular on devices that support a filesystem keyring, where we need
to do some additional setup before the devices can be used.
While we could modify StorageManagerService to delay the mount, a safer
fix at this stage of the release is to just fix the ordering of these
events. To achieve that, add a simple postMount() helper, that is called
after a succesful mount. This allows us to setup the volume properly
before trying to mount any stacked volumes.
Bug: 151079464
Test: atest AdoptableHostTest
Change-Id: I2cc4113d4d71d89aa629bb9c0fa9be441355c079
To improvement performance, and also making them able to list
the dirs.
This should also be fine under b/151055432, as the whole obb
directory is mounted, renameTo() from installer to apps should be
a move not copy.
Bug: 153422990
Bug: 153540919
Test: atest AdoptableHostTest
Change-Id: Ia18fd4393db14a0f11d6e5b947dd716515bdeeef
Because we want all other paths (in particular Android/media) to go
through FUSE.
Also use scope_guard to make unwinding some failures easier.
Bug: 151272568
Test: atest AdoptableHostTest
Change-Id: Ib487b9071b5b212c7bb12ce54f80c96d98acaef5
In EmulatedVolume#doMount, if some operations fail, we call
EmulatedVolume#doUnmount.
During this unmount we try to unmount Android/ causing a FUSE_LOOKUP
on the FUSE mount. If the FUSE mount is not up, this can hang.
Now we introduce a new state to prevent unmounting Android/ if it
wasn't mounted.
Test: atest AdoptableHostTest
Bug: 151685786
Change-Id: I6246d3910c352034d2a4fb09ad9c1e7fd91cba5e
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
Since ext4 currently doesn't have the required kernel patches in place
on cuttlefish.
Bug: 150935323
Test: sm set-virtual-disk true
sm partition disk:7,xyz private
inspect mount output
Change-Id: Ief5bd9ace9d39bdfbae8d3857044a2143801f6be
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
The dm-crypt solution requires a kernel patch that won't be present in
the GKI kernel, while the new metadata encryption system in the GKI
kernel solves this problem in a much cleaner way.
Test: create private volume on Cuttlefish, setting property both ways.
Bug: 147814592
Change-Id: Ie02bd647c38d8101af2bbc47637f65845d312cea
For some reason this can be racy; until we understand the root cause,
retry to unblock AdoptableHostTest.
Bug: 149396179
Test: atest AdoptableHostTest no longer hangs
Change-Id: I162ff8ad305535e7a4fab3d88f38b687b50cf4a3
