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
This is already on for all Pixel devices with no problems observed.
If this causes issues with a specific device (e.g. vendor apps being
unable to access their data) it can be temporarily disabled by adding
PRODUCT_PROPERTY_OVERRIDES += ro.vold.level_from_user=0
to the device.mk file. Please file a bug if that happens.
Bug: 141677108
Test: presubmits
Change-Id: Ic9da534f1a5f4c9e3bd62ea5c09a3b11ebcb33e7
Merged-In: Ic9da534f1a5f4c9e3bd62ea5c09a3b11ebcb33e7
(cherry picked from commit 763393644a)
As storage is not mounted in system server, we use vold
to check if storage app data and obb directories exist instead.
We add a method in vold so it only creates app data and obb dirs
if dirs do not exist to speed up app starting time.
Bug: 160336374
Test: Data and obb directories are created when a new app is started
Change-Id: I1bd784d9c9e05463f71433fc782ac4e0c831cbf1
Since /storage/emulated/userId isn't accessible for users != userId,
and vold should anyway try to avoid accessing the FUSE filesystem itself.
Bug: 172078780
Test: atest StorageManagerTest --user-type secondary_user
Change-Id: I98222bf844a6b7d8ec0d9873eddc71f61aa68c90
There've been reports of issues where, when a volume is ejected, the
MediaProvider process gets killed. This happens because the
MediaProvider has a file open on the volume (eg, during a scan). We do
abort the scan when the volume is ejected, however this could take some
time. So, we give MediaProvider a bit more time before getting killed,
by only looking for files open on the pass_through paths last. This
order anyway seems to make more sense - ideally we kill apps using
external storage before we unmount the pass_through path underlying it.
Bug: 171367622
Test: atets AdoptableHostTest
Change-Id: Ie8eacaa72a80ff8161ecf1e8c0243afcd890ee39
