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
On devices without sdcardfs, /Android/data/com.foo and
/Android/obb/com.foo can be written by other processes (eg installers);
in those cases, file ownership may be wrong. To ensure that the original
app always has access to the files contained in this directory, add a
group to the default ACL that matches the UID of the app. Since all apps
have their own UID also as their group ID, this ensures that things keep
working correctly.
Bug: 157530951
Test: atest
android.appsecurity.cts.ExternalStorageHostTest#testExternalStorageUnsharedObb
Change-Id: I829a2a7c7b578a8328643f38681e68796adcd6b2
Change-Id: Ibbc333fb395507363830dfcf5dc6f1cfd55f008d
FuseDaemonHostTest is migrated to CTS and renamed to
CtsScopedStorageHostTest.
Bug: 142926859
Test: atest --test-mapping
Change-Id: I24c74e20909ccf8868d1487e1cc93f6f2c0108fc
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
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
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
This reverts commit ab7c958cc5.
Reason for revert: ARC is migrating to ARCVM on R, which doesn't use AppFuse any more.
Bug: 110379912
Test: m
Change-Id: Icc827c59530274421e4c94789d96fd3d287e591e
So Android/data and Android/obb won't be accessing fuse anymore,
and apps should not see other packages as well as it's sandboxed
the tmpfs.
Bug: 155462341
Test: atest AppDataIsolationTests pass after feature flag is on
Change-Id: I5658440772e669c1235d318f708a3d336523754f
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
Vold needs to pass / accept IncFs control via Binder, so it
neeeds to get and put its internal FDs in and out. Using the new
release() function it works without extra fd duping
Bug: 153704006
Test: builds & boots
Change-Id: I64bc5b1ca9f2c69e34c3a860ed3edbe58bd9ea29
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
While looking at some emulator logs, I noticed that we fail to create
dirs like /Android/data/com.foo/cache on public volumes, because we try
to chmod it; public volumes go completely through FUSE, even for
Android/, and so these operations will fail, because the underlying
UID/GID is not setup correctly.
Really the only thing we really have to do on public volumes is create
the dirs, like we used to do.
Bug: 152618535
Test: manually verify cache dirs can be created successfully
Change-Id: I66e5d0873f1198123787943b17b468eadf0a853d
To make it easier to support disk formats created using old versions
of dm-default-key with new kernels, choose the disk format to use
based on options_format_version and first_api_version properties
instead of checking the version number of the kernel module.
Bug: 150761030
Test: crosshatch and cuttlefish boot normally; cuttlefish
fails with "default-key: Not enough arguments" as expected when
option is set to 1
Cherry-Picked-From: f56d553babc368e557fe90513e78a5ba06626b0d
Merged-In: Ib51071b7c316ce074de72439741087b18335048c
Change-Id: Ib51071b7c316ce074de72439741087b18335048c
Vold now does not check caller's permission, but only accepts
transactions from system_server. And it's up to system server to do the
right thing and check permissions/appops.
Bug: b/152633648
Test: atest PackageManagerShellCommandTest PackageManagerShellCommandIncrementalTest
Test: adb shell appops set 1000 GET_USAGE_STATS deny
Change-Id: Id56c1673b135b72b3ec86e572aa4bcca3afc19ab
Test: Manually verified ownership of /storage/emulated/0/Android/data on cf_x86_phone-userdebug after enabling feature
Bug: 151455752
Change-Id: I75a1e3b769476e56094e41d82e7f8e1a72827ded
Vold incorrectly sends the earlyBootEnded signal only to the Keymaster
instance used for device encryption, but all of them need it.
Bug: 152932559
Test: VtsHalKeymasterV4_1TargetTest
Change-Id: Id8f01a1dc7d2398395f369c3ea74656a82888829
am skip reason: Change-Id Id8616804bba622226ca21b8eff0d3eb577b4b7e0 with SHA-1 1dd5c4f787 is in history
Change-Id: Iaffd50d7b736066cfa429edf28b3f18fb956715d
+ Get rid of an extra string copy in path validation function
Bug: 152349257
Test: atest vold_tests
Change-Id: I03a8cab0dd6abd7d5c9dcbbc2acb651e818e6cd8
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
These were only added for ext4.
Bug: 150935323
Test: when creating a private f2fs volume, things work as expected.
Change-Id: I11ee04bfddecb6c95e223e66c9bf532c425e6fac
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
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