security_context_t has been marked as deprecated in libselinux from
version 3.2. Update to the `char*` type.
Bug: 190808996
Test: m
Change-Id: I6f40e161251c79893d41e12c368715736578aacc
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
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: Ic5d63457ec917ea407b900dbb7773d89311780c6
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
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
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
Remove the error-prone 'keepOld' parameter, and instead make begin()
(renamed to BeginKeymasterOp()) do all the key upgrade handling.
Don't handle /data and /metadata differently anymore. Previously, when
a checkpoint is active, key blob files were replaced on /data
immediately; only the actual Keymaster key deletion was delayed until
checkpoint commit. But it's easier to just delay the key blob file
replacement too, as we have to implement that for /metadata anyway.
Also be more vigilant about deleting any leftover upgraded keys.
Test: Tested on bramble using an OTA rvc-d1-release => master. In OTA
success case, verified via logcat that the keys were upgraded and
then were committed after the boot succeeded. In OTA failure
case, verified that the device still boots -- i.e., the old keys
weren't lost. Verified that in either case, no
keymaster_key_blob_upgraded files were left over. Finally, also
tried 'pm create-user' and 'pm remove-user' and verified via
logcat that the Keymaster keys still get deleted.
Change-Id: Ic9c3e63e0bcae0c608fc79050ca4a1676b3852ee
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
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
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 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
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
- 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
This was hard to read and understand. Instead, fall back to explicit
string operations with more comments on what we're doing and what we're
allowing.
This also fixes an issue where apps were asking us to create dirs on
their behalf that our more than 2 levels deep, eg
com.foo/files/downloads ; I thought such paths weren't allowed, but
apparently they are (and there's no good reason for us to not set them
up correctly).
Bug: 149407572
Test: launch opera
Change-Id: I7c64831032b66e90960b96e41ee42c7d616a759c
A regex allows us to be more specific in what kind of directories we
accept here, which in turn makes it easier to correctly create them.
Bug: 146419093
Test: atest FuseDaemonHostTest
Change-Id: Icb8911f6516eab81b9bbd567c7287be9f605e8b0
This allows setting the "inherit project ID" flags on directories; in
our case, we want to set this on the root of the lower filesystem, eg
"/data/media/0".
Bug: 146419093
Test: manual invocation works
Change-Id: Ic74588fd972d464e7021bef953da0e5aaafc4286
Use PrepareAppDirsFromRoot() to setup the quota project ID on
application-specific directories correctly. App directories use
AID_EXT_GID_START + their application ID offset, whereas cache
directories use AID_CACHE_GID_START. This is consistent with the GIDs
sdcardfs used to label these directories with.
Bug: 146419093
Test: verified project IDs with lsattr -p
Change-Id: Idca8a30d185012efb0d19ceb9b346b9a4de34f18
Normally sdcardfs takes care of setting up these directories on-demand,
for example when an app requests its private data directory to be
created. On devices without sdcardfs however, we ourselves need to make
sure to setup the UID/GID of these directories correctly.
Introduce a new PrepareAndroidDirs() function which sets the dirs up
correctly. On devices without sdcardfs, that means:
Path UID GID mode
/Android media_rw media_rw 771
/Android/data media_rw ext_data_rw 771
/Android/obb media_rw ext_obb_rw 771
Bug: 146419093
Test: wipe Android/, reboot, with and without sdcardfs, verify
contents
Change-Id: I3a879089422c7fc449b6a3e6f1c4b386b86687a4
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
With the newly added flag for Settings developer options, which is now
used to change the state of FUSE, PROP_FUSE now acts as the snapshot
feature flag for the current boot.
Bug: 145391093
Test: atest AdoptableHostTest
Change-Id: I22363b088e88c764294cbd61c6d94160c907fae3
The pass-through mount is used by MediaProvider to access external
storage. Previously, it was the raw filesystem (eg ext4/f2fs); the
problem with that is that the permissions on that filesystem don't allow
MediaProvider to access all the files it needs to - in particular
directories under Android/
To solve this problem, we can have the pass-through mount sit on top of
sdcardfs instead of the raw filesystem. This means we need to mount
sdcardfs even in case we're using FUSE, but we already needed to do this
anyway for other performance reasons.
Bug: 135341433
Test: atest AdoptableHostTest
Change-Id: I893d5e5076c5096d2d55212f643c9a857242e964
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
This will allow us to receive values from server flags and store them in
persist.sys.fuse without risking flag consistency during a boot.
Test: manual - flip persist.sys.fuse both ways and make sure FuseDaemon
works as expected.
Bug: 140803239
Change-Id: I839a1973c98b4eda982226d20be48d1c08e7464a
Also allow the state just before doMount() as a valid state for setting
fuse fd.
Test: manual
BUG:140173712
Change-Id: I012f8a83fef00e68f33010954fbc2ebc53cf8f1d
Since system_server cannot mount devices by itself,
add a binder interface to vold that system_server
can call to initiate this mount when required.
BUG: 135341433
Test: manual
Test: atest --test-mapping packages/providers/MediaProvider
Test: ExternalStorageHostTest DownloadProviderTests
Change-Id: If4fd02a1f1a8d921a3f96783d8c73e085c5b7ca1
We need this to stay mounted at /storage.
Bug: 124466384
Test: manual
Test: atest cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ExternalStorageHostTest.java
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: I0cc835471ced2822d83d7056bec53d62ddc682f0
Update vold to only create package sandboxes and not do any bind mounts.
After zygote forks, all the necessary bind mounts will be setup for
the process.
Bug: 124009234
Test: manual
Test: atest cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ExternalStorageHostTest.java
Test: atest DownloadProviderTests
Test: atest cts/tests/app/src/android/app/cts/DownloadManagerTest.java
Test: atest MediaProviderTests
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: Ia42209cb74cbc423bb09c1c51cb7a164f7c568da
