These paths previously had 0755 permission bits
(/mnt/installer got its bits from the /mnt/user bind mount).
With such permissive bits, an unauthorized app can access a file using
the /mnt/installer path for instance even if access via /storage
would have been restricted.
In init.rc we create /mnt/user with 0755 initially, this is to keep
/sdcard working without FUSE. When mounting a FUSE filesystem, we
enusure in vold that /mnt/user is changed to 0700
Bug: 135341433
Test: adb shell ls -d /mnt/{user, installer}
Change-Id: Id387e34c5fd257858861246ad51486892653fb3a
This CL updates vold to use the Keymaster 4.1 interface, but does not
yet call any of the new methods.
Test: Boot the device
Change-Id: I4574a2f6eead3b71d1e89488b496b734694620c7
AIDL import path should point to a root directory where relative path to
an AIDL file encodes the fully qualified name of the type in the file.
Since libvold_binder imports types like
android.os.incremental.IncrementalFileSystemControlParcel which are
under frameworks/base/core/java, the import path should set to the path,
not to the sub directory that directly has the AIDL files.
Bug: 147918827
Test: m
Change-Id: Ic4941578813eced5a7eb59a0656c10b76e902515
This gives x permission to all on the parent apex data directory
so that the data directories can be accessed by modules.
Bug: 147848983
Test: Build & flash, check permissions are correct
Change-Id: I1bbf480cbf9f9e758353237e333317516ad375ee
The apex data directories must be accessed by apexd in order for it to
perform snapshot and restore as part of the rollback process. As apexd
runs as root, this CL changes the apex data directories under misc_[ce|de]
to be owned by root.
Bug: 141148175
Test: Build and flash; check permissions are set correctly.
Change-Id: Icf2059cc9448364f834eef7892914a99883746a1
This allows readlink(2) of /sdcard paths to work correctly
and return /storage/emulated/<userid> instead of
/mnt/user/<userid>/emulated/<userid>
Test: readlink /sdcard -> /storage/emulated/0
Bug: 135341433
Change-Id: I2cfa9cede02a93024e41d90f17c926a69ec6e052
CE keys were cached in vold to support untrusted reset
by a device admin, this is now supported by Locksettingservice
using synthetic password. This change requires a secret to be
provided to retrieve the CE key and re-wrap without the secret
when user removes the credential.
Test: Set credential, remove credential, swipe to none
and vice-versa.
Bug: 26948053
Change-Id: I4cb1c035a472477e70c1ff5bf0b2c3fcfad495e5
When we try mounting an EmulatedVolume, we may mount sdcardfs but fail
in any of the FUSE mounts, in this case we should unmount whatever
mounts we made during the mount.
Test: Intentionally causing a partial failure, verified that sdcardfs
gets unmounted
Bug: 147610762
Change-Id: I29ed044ed8ab8aa3dd83bc97a49eb3140ce4fe27
Installers will be allowed to write OBB for any application; this is not
easy to achieve on sdcardfs, where the GID of Android/obb is the same as
the GID of Android/data (app-private data), meaning giving installers
write access to Android/obb would also give them write access to
Android/data.
Instead, we create a /mnt/installer view, which is exactly the same as
/mnt/user, with the sole exception that the write sdcardfs view of
Android/obb is mounted on top. This is what will allow installers to
write there, while still being restricted with respect to app-private
data in Android/data.
Bug: 134706060
Test: atest AdoptableHostTest
Change-Id: If2b93870a877efef182bdc06466552a7527499ad
This is a slave bind mount of /mnt/user, created before we create the
two mount namespaces. Unmounting it here prevents us from re-creating it
in the right way, so leave it alone.
Bug: 134706060
Test: verify mount is still there after vold starts
Change-Id: Iaac91953cbb9abfef0aaac60f74b99b16c943f87
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
When the partition is f2fs and the OS is 32bit, the data.f_bavail and
data.f_frsize are 32 bits in size. The product of them is also 32 bits
in size. If the available size of storage is greater than 4G, the
product may be greater than the unsigned long max value. If the product
is overflow and less than 100M. The UDC feature will be disabled.
There is also an overflow for std::strtoul when the variable content
is a very big number(more the unsigned long max value).
To avoid the overflow:
1. convert the variable data.f_bavvail to uint64_t and then compute the
multiplication.
2. use std::strtoull replace to std::strtoul.
Bug: 147118861
Change-Id: I60172ae4cb7c997e2ad4a36583be74736c25e565
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
