Since we no longer have the Fuse Daemon, we won't ever
need to stop the daemon when unmounting.
Bug: 33808187
Test: Run "adb shell ps | grep -w Z"
The sdcard daemon should not be listed.
Change-Id: I6bb9341785b711d81553393f7c3b56115c435236
When waitpid is successful, we need to reset mFusePid
since mFusePid will be killed again unnecessarily
in doUnmount() if we don't reset mFusePid.
As a result, it will kill another unrelated process
in the case of pids wrap around.
Test: reboot
Fixes: 1d79d10 ("Check if sdcard daemon exited.")
Change-Id: Icb422d5c81621f9f6b9f4b1218e94b1d89172763
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
This reverts commit a3a60b372e.
Reason for revert: All kernel prebuilts merged
(cherry picked from commit 75ae529bf8)
Bug: 65600849
Bug: 65573871
Test: m
Change-Id: I75b0cb1d82213b875cbef8d39f4f1a8fb34b9795
This reverts commit 1b38e33003.
Causes a boot loop on bullhead.
(cherry picked from commit a3a60b372e)
Bug: 63245673
Bug: 65660058
Test: m
Merged-In: I9c8afd3ba22547aff5aff06b71cb8ff3b8a07350
Change-Id: I9c8afd3ba22547aff5aff06b71cb8ff3b8a07350
This sdcardfs feature was moved under a mount option
and is only needed on private volumes
Test: Private emulated volume should attempt to mount with
derive_gid option.
Bug: 63245673
Change-Id: I40a8b15c298c815a4643007b9eca8269379fd2ac
This sdcardfs feature was moved under a mount option
and is only needed on private volumes
Test: Private emulated volume should attempt to mount with
derive_gid option.
Bug: 63245673
Change-Id: I40a8b15c298c815a4643007b9eca8269379fd2ac
If the system is using sdcardfs, the sdcard daemon exits after mounting.
If it's using FUSE, the sdcard daemon runs until we go to unmount.
Bug: 37638548
Test: Run "adb shell ps | grep -w Z" with sdcardfs enabled.
The sdcard daemon should not be listed.
Run again with sdcardfs disabled. The daemon should be
running, and vold should not be stuck waiting on it.
Change-Id: I930d22b35194ec99e7a6a4a022a04d36f4f39a34
When unmounting an emulated volume, look for apps with open files
using the final published volume path.
Without this change, we were only looking at the internal paths
used for runtime permissions, which apps never use directly. This
meant we'd always fail to unmount the volume if apps didn't respect
the EJECTING broadcast, and volume migration would end up wedged
until the device rebooted.
Bug: 24863778
Change-Id: Ibda484e66ab95744c304c344b226caa5b10b7e2e
We have a bunch of magic that mounts the correct view of storage
access based on the runtime permissions of an app, but we forgot to
protect the real underlying data sources; oops.
This series of changes just bumps the directory heirarchy one level
to give us /mnt/runtime which we can mask off as 0700 to prevent
people from jumping to the exposed internals.
Also add CTS tests to verify that we're protecting access to
internal mount points like this.
Bug: 22964288
Change-Id: I83f09f0423f4993e766273c50389dd29b1c50589
We really only support a single emulated volume on the device at a
time, either on internal storage, or moved to a private volume. To
avoid kicking off a giant rescan of all media when moved, keep all
the paths the same when mounted as primary.
Also ensure we have /data/media/0 ready on private volumes.
Bug: 20275423
Change-Id: I0c102f430b865ca7536772b1fae56d8c9660a97a
In order to compare results from readlink() calls, we need to null
terminate the read value, otherwise we can end up doing an infinitely
recursive remount in the root namespace.
When remounting inside a namespace, unmount all existing mounts before
mounting the new storage into place. This also means we need to mount
the user-specific symlinks back into place.
Skip spinning up the FUSE daemon when not visible, otherwise we get
stuck waiting for a daemon that never shows up.
Bug: 22192518, 22204412
Change-Id: Icc7db822354ab7ffc47c39cd0611f65edecc32e5
Now that we're treating storage as a runtime permission, we need to
grant read/write access without killing the app. This is really
tricky, since we had been using GIDs for access control, and they're
set in stone once Zygote drops privileges.
The only thing left that can change dynamically is the filesystem
itself, so let's do that. This means changing the FUSE daemon to
present itself as three different views:
/mnt/runtime_default/foo - view for apps with no access
/mnt/runtime_read/foo - view for apps with read access
/mnt/runtime_write/foo - view for apps with write access
There is still a single location for all the backing files, and
filesystem permissions are derived the same way for each view, but
the file modes are masked off differently for each mountpoint.
During Zygote fork, it wires up the appropriate storage access into
an isolated mount namespace based on the current app permissions. When
the app is granted permissions dynamically at runtime, the system
asks vold to jump into the existing mount namespace and bind mount
the newly granted access model into place.
Bug: 21858077
Change-Id: Iade538e4bc7af979fe20095f74416e8a0f165a4a
When requested, kick off a thread that will migrate storage contents
between two locations. This is performed in several steps that
also interact with the framework:
1. Take old and new volumes offline during migration
2. Wipe new location clean (10% of progress)
3. Copy files from old to new (60% of progress)
4. Inform framework that move was successful so it can persist
5. Wipe old location clean (15% of progress)
Derives a hacky progress estimate by using a rough proxy of free
disk space changes while a cp/rm is taking place.
Add new internal path for direct access to volumes to bypass any
FUSE emulation overhead, and send it to framework. Remove mutex
around various exec calls since setexeccon() is already per-thread.
Bug: 19993667
Change-Id: Ibcb4f6fe0126d05b2365f316f53e71dc3e79a2b8
When a private volume is mounted, create an emulated volume above it
hosted at the /media path on that device. That emulated volume is
automatically torn down when unmounting the private volume.
Add "removed" state for volume, which signals to framework that
media has left the building, send when the volume is destroyed.
Bug: 19993667
Change-Id: I1f82b51de578ac5cfcc5d7b9a6fb44f6f25c775c
This adds support for private volumes which is just a filesystem
wrapped in a dm-crypt layer. For now we're using the exact same
configuration as internal encryption (aes-cbc-essiv:sha256), but we
don't store any key material on the removable media. Instead, we
store the key on internal storage, and use the GPT partition GUID
to identify which key should be used.
This means that private external storage is effectively as secure as
the internal storage of the device. That is, if the internal storage
is encrypted, then our external storage key is also encrypted.
When partitioning disks, we now support a "private" mode which has
a PrivateVolume partition, and a currently unused 16MB metadata
partition reserved for future use. It also supports a "mixed" mode
which creates both a PublicVolume and PrivateVolume on the same
disk. Mixed mode is currently experimental.
For now, just add ext4 support to PrivateVolume; we'll look at f2fs
in a future change. Add VolumeBase lifecycle for setting up crypto
mappings, and extract blkid logic into shared method. Sprinkle some
more "static" around the cryptfs code to improve invariants.
Bug: 19993667
Change-Id: Ibd1df6250735b706959a1eb9d9f7219ea85912a0
Wire up new Disk and VolumeBase objects and events to start replacing
older DirectVolume code. Use filesystem UUID as visible PublicVolume
name to be more deterministic.
When starting, create DiskSource instances based on fstab, and watch
for kernel devices to appear. Turn matching devices into Disk
objects, scan for partitions, and create any relevant VolumeBase
objects. Broadcast all of these events towards userspace so the
framework can decide what to mount.
Keep track of the primary VolumeBase, and update the new per-user
/storage/self/primary symlink for all started users.
Provide a reset command that framework uses to start from a known
state when runtime is restarted. When vold is unexpectedly killed,
try recovering by unmounting everything under /mnt and /storage
before moving forward.
Remove UMS sharing support for now, since no current devices support
it; MTP is the recommended solution going forward because it offers
better multi-user support.
Switch killProcessesWithOpenFiles() to directly take signal. Fix
one SOCK_CLOEXEC bug, but SELinux says there are more lurking.
Bug: 19993667
Change-Id: I2dad1303aa4667ec14c52f774e2a28b3c1c1ff6d
This is the first in a series of changes that are designed to
introduce better support for dynamic block devices.
It starts by defining a new Volume object which represents a storage
endpoint that knows how to mount, unmount, and format itself. This
could be a filesystem directly on a partition, or it could be an
emulated FUSE filesystem, an ASEC, or an OBB.
These new volumes can be "stacked" so that unmounting a volume will
also unmount any volumes stacked above it. Volumes that provide
shared storage can also be asked to present themselves (through bind
mounts) into user-specific mount areas.
This change also adds a Disk class which is created based on block
kernel netlink events. Instead of waiting for partition events from
the kernel, it uses gptfdisk to read partition details and creates
the relevant Volume objects.
Change-Id: I0e8bc1f8f9dcb24405f5e795c0658998e22ae2f7
Daniel Rosenberg
Gao Xiang
Rom Lemarchand
Richard Uhler
Elliott Hughes
Narayan Kamath
Jeff Sharkey
Dan Albert