Constant to indicate a regular scoped storage view, with the sole
exception that Android/ should be writable.
Bug: 134706060
Bug: 146490513
Test: builds
Change-Id: Ifbcd4fd912ed4cc18d7c6e3eab2c582bc862e10c
We bind mount /mnt/user/<userid> onto /storage for normal apps and
/mnt/pass_through/<userid> for special apps like the FUSE daemon or
the old android.process.media hosting the DownloadManager. This bind
mount allows app have /storage/self/primary which is what /sdcard
symlinks to.
Before this change, we were not creating the self/primary symlink on
/mnt/pass_through/<userid> so trying to access /sdcard from the
DownloadManager would fail.
Bug: 135341433
Test: atest android.app.cts.DownloadManagerTest#testAddCompletedDownload_invalidPaths
Change-Id: I660139be3d850e6e9ea4705f86ef2b5872ddca16
In preparation of sdcardfs going away on devices launching with R,
conditionally use it.
Bug: 146419093
Test: cuttlefish with sdcardfs, cuttlefish without sdcardfs but with
FUSE
Change-Id: I2c1d4b428dcb43c3fd274dde84d5088984161993
Making FUSE request from vold is risky because the FUSE daemon may be
down and vold could get wedged.
Additionally, the FUSE daemon only responds to requests with matching
user id paths, i.e requests on /mnt/user/0/emulated/10 will fail.
So if vold (running as user 0) makes a request on
/storage/emulated/10, it really means /mnt/user/0/emulated/10
which will fail if it gets to the FUSE daemon.
TODO: Fix the lower filesystem paths to support devices without
sdcardfs
Bug: 141540368
Change-Id: I90d698f6aecd114d75b6d578ad08620988da7d7d
atest: atest android.appsecurity.cts.ExternalStorageHostTest#testMediaSandboxedFull
Previously, when mounting a FUSE volume, the permission bits for
/mnt/user/<userid> were very strict, 700 which was good, however this
value was ignored because it was overriden in zygote to 755. In fact
if it wasn't ignored, apps wouldn't have had access to /sdcard becase
they would lack the directory 'execute' bit for /mnt/user/<userid>
needed while looking up /mnt/user/<userid>/emulated
Now we set it to a strict enough value, 710 that only allows apps
running under the same user id to lookup /mnt/user/<userid>.
This ensures that user 10 cannot access /mnt/user/0.
A special case is added for /mnt/user/0 for shell since it is not in
the 'everybody' group and would otherwise not be able to 'adb shell ls
/sdcard'
Bug: 135341433
Test: atest -c android.appsecurity.cts.ExternalStorageHostTest#testSecondaryUsersInaccessible
Change-Id: Ia427d1b69c7140254ae3459b98e51531d8322f1a
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
time_started in encryptGroupsData is set from and compared to
clock_gettime(CLOCK_MONOTONIC, ...) nearly everywhere: "Clock that
cannot be set and represents monotonic time since some unspecified
starting point". However in cryptfs_enable_inplace_f2fs() it is set
from a different clock, time(NULL), with the result that the setprop
calls that indicate progress are wrong and can be called much too
often. The fix is to make this function consistent with
cryptfs_enable_inplace_ext4.
Bug: 146877356
Change-Id: I2707180e5c5bf723a5a880f6a3aac47f2bb34ccd
- Use FSCRYPT_MAX_KEY_SIZE from <linux/fscrypt.h> instead of manually
defining FS_AES_256_XTS_KEY_SIZE. These have the same numeric value
(64), but the former is supposed to be used, and AES-256-XTS isn't
necessarily the encryption algorithm that is being used anyway.
- Use the new name FSCRYPT_KEY_DESCRIPTOR_SIZE instead of the old name
FS_KEY_DESCRIPTOR_SIZE. These have the same numeric value (8).
- Don't try to handle sizeof(fscrypt_key::raw) > FSCRYPT_MAX_KEY_SIZE,
as this simply isn't the case.
- Set fscrypt_key::mode to 0 rather than FS_ENCRYPTION_MODE_AES_256_XTS.
This field has always been ignored by the kernel, and AES-256-XTS
isn't necessarily the encryption algorithm that is being used anyway.
- Initialize the fields of fscrypt_key in order.
This is a cleanup only.
Test: booted hikey with fileencryption=aes-256-xts and a kernel that
doesn't support the new fscrypt ioctls.
Bug: none
Change-Id: Ie2a7e9240aa479dfab2765c11db8a7124d20c643
If vold's view of /storage is FUSE, it means that creation of
directories in Android/ will go through FUSE as well. The implementation
of fs_mkdirs() tries to opendir() individual parts of the entire path;
so for a path "/storage/emulated/0/Android", it will try to opendir()
"/storage", "/storage/emulated", etc.
By default, "/storage/emulated" is created with 711 permissions; while
vold itself is root, access to /storage/emulated is routed through
MediaProvider (because of FUSE), and MediaProvider doesn't run as root,
nor does it have the capabilities to bypass the ACL. This means that
fs_mkdirs() as it is will fail, because opendir("/storage/emulated")
will fail from MediaProvider.
To prevent this, route these accesses directly to the lower filesystem
(currently, sdcardfs), by renaming the paths.
Bug: 146189163
Test: atest AdoptableHostTest
Change-Id: Idbb41b9ffad9713f3b255c51bd4de16f4d090223
aosp/1184798 has updated the kernel headers to 5.4, so we no longer need
the file fscrypt_uapi.h. In KeyUtil.cpp we also now don't need
<linux/fs.h>, but rather just the more specific <linux/fscrypt.h>.
Test: build
Bug: None
Change-Id: I56d17826eb7c3b95c74ce0435a4feae7f3cc325e
Now that StorageManager asks vold to create package directories again,
apps only need write access in their own app-private directory. Both
app-private and OBB dirs will be created by privileged daemons as
needed.
This means we can use the "default" sdcardfs view for the Android/
bind-mount again. This has the added benefit that it fixes shell, which
wasn't in the "everybody" group, and therefore suddenly couldn't enter
/sdcard/Android anymore.
Bug: 146189163
Test: atest AdoptableHostTest
Change-Id: I37ca3b19ea4d11ed866efa808f51be945a4dc080
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
* changes:
Use a regular set for started users.
When unmounting, only kill user-specific paths.
Bind mount Android/ directory in FUSE.
Use sdcardfs for pass-through mounts.
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
The path for emulated volumes is set to /storage/emulated,
not /storage/emulated/<userid> . When unmounting, we only
want to kill process with a reference to /<userid>; this prevents
killing processed needlessly.
Bug: 137890172
Test: atest AdoptableHostTest
Change-Id: I70e36e87077e87db9b3c7e07dc0e481ba06c2c14
For apps seeing the FUSE filesystem, we want to bind-mount the Android/
directory to the lower filesystem. The main reason for this is game
performance - Android/ contains both OBBs and app-private external data,
and both are heavily accessed during game startup. This is a pretty
straightforward bind-mount on top of /mnt/user.
Bug: 137890172
Test: Running the following:
df /storge/emulated/0 ==> /dev/fuse (FUSE)
df /storage/emulated/0/Android ==> /data/media (sdcardfs)
Test: atest AdoptableHostTest
Change-Id: Ic17a5751b5a94846ee565ff935644a078044ab06
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
Martijn Coenen
Zim
Automerger Merge Worker
Denis Hsu
Treehugger Robot
Eric Biggers
Abhijeet Kaur
Greg Kaiser
Nikita Ioffe
Tianjie Xu
Oli Lan