Select whichever is real dir instead of symbolic link from either /data/data
or /data/user/0. This is to minimize path walking overhead in kernel.
This works together with Change 369787
Test: Manual test
Change-Id: I338518673fc22ccbfed6ddd6be196931fce18525
Signed-off-by: cjbao <cathy.bao@intel.com>
The original default /fstab.{ro.hardware} might be moved to /vendor/etc/.
or /odm/etc/. Use the new API to get the default fstab instead of using
the hard-coded /fstab.{ro.hardware}.
Bug: 35811655
Test: boot marlin with /vendor/etc/fstab.marlin
Change-Id: I92d6aefe6ff3433b7d1a671358d990bb7b1f2150
We simplified the way we track whether or not a dex file is used by
other apps. DexManger in the framework keeps track of the data and we
no longer need file markers on disk.
Test: device boots, foreign dex markers are not created anymore
Bug: 32871170
Change-Id: Id0360205b019be92049f36eab4339f4736e974f4
* Use const reference type for for-loop index variables
to avoid unnecessary copy.
Bug: 30413223
Change-Id: Id4d980ae8afec1374fc3be0b23f1c6a39bff86e0
Test: build with WITH_TIDY=1
On FBE devices, the filenames inside credential-encrypted directories
are mangled until the key is installed. This means the initial
restorecon at boot needs to skip these directories until the keys
are installed.
This CL uses an existing facility to request that init run a
recursive restorecon over a given path, and it requests that
operation for the CE directories that would have been omitted by
the SKIPCE flag earlier during boot.
Bug: 30126557
Change-Id: I8c7abea27215075a091f615a7185a82a2f4a4a95
Preparing and destroying users currently needs to be split across
installd, system_server, and vold, since no single party has all the
required SELinux permissions.
Bug: 27896918, 25861755
Change-Id: Ieec14ccacfc7a3a5ab00df47ace7318feb900c38
Currently, vold only supports MMC (for SD cards) and SCSI (for USB
drives) devices. It does not recognize any device whose major number is
not one of those used by MMC and SCSI. Unfortunately, virtio-blk is one
such device. It is used by the new Android emulator (a.k.a. qemu2,
featuring the "ranchu" virtual board) for SD card emulation.
In order to make this virtio-blk based SD card device appear in Android
and appear as an SD card (rather than a USB drive), changes have to be
made to both vold (wherever the device major number is checked) and
ranchu's storage configuration. This CL implements former.
This is a stop-gap solution for emulator in nyc.
A longer term solution in-tune with upstream kernel is in the pipes.
Updated from aosp/master version.
BUG:27431753
Change-Id: I5014edec73be7c5b565d91542464c82cbe58992c
Signed-off-by: Yu Ning <yu.ning@intel.com>
(cherry picked from commit 5b1d1c7dfa13b4dca75213581dc8351b841b76c8)
This is a special profile folder where apps will leave profile markers
for the dex files they load and don't own. System server will read the
markers and decide if the apks should be fully compiled instead of
profile guide compiled.
Bug: 27334750
Bug: 26080105
Change-Id: Ib18f20cf78a8dbfc465610ec6ceec52699c5420a
Give callers the option of preparing CE and/or DE storage. The
framework will only prepare CE storage after the CE keys have been
unlocked for that user.
When init is calling enablecrypto, kick off the work in a thread so
that we can make other calls back into vold without causing
deadlock. Leaves blocking call intact for framework callers.
Clean up 'vdc' tool to send useful transaction numbers, and
actually watch for the matching result to come back. This fixes
race conditions when there are multiple 'vdc' callers.
Also add other system and misc directories to match spec.
Bug: 25796509
Change-Id: Ie4f853db6e387916b845d2b5fb92925d743b063d
When FBE emulation is enabled, lock/unlock the media directories that
store emulated SD card contents.
Change unlocking logic to always chmod directories back to known
state so that we can recover devices that have disabled FBE
emulation.
Bug: 26010607, 26027473
Change-Id: I6d4bff25d8ad7b948679290106f585f777f7a249
We now have separate methods for key creation/destruction and
unlocking/locking. Key unlocking can pass through an opaque token,
but it's left empty for now.
Extend user storage setup to also create system_ce and user_de
paths. Bring over some path generation logic from installd.
Use strong type checking on user arguments.
Bug: 22358539
Change-Id: I00ba15c7b10dd682640b3f082feade4fb7cbbb5d
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
The expression otherwise overflows for large devices.
It's fsblkcnt_t -> unsigned long, which is 32 bit on ARMv7.
Change-Id: I46c5e00558b7dbd6abd50fae4727396079044df2
Otherwise blkid can emit tags like SEC_TYPE which mess with the value
extraction code.
Bug: 23069906
Change-Id: Id2a588ff43a538747d1e44cd8218c96ebd0192c2
Refactor fstrim code to be encapsulated in unique task object, and
give it option of benchmarking when finished. Trimming now includes
both storage from fstab and adopted private volumes. Cleaner timing
stats are logged for each unique volume.
Add wakelock during ongoing async move tasks. Push disk sysfs path
to framework so it can parse any SD card registers as desired.
Bug: 21831325
Change-Id: I76577685f5cae4929c251ad314ffdaeb5eb1c8bf
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
Report both the disk and the partition GUID for private volumes to
userspace, and offer to forget the encryption key for a given
partition GUID.
Bug: 21782268
Change-Id: Ie77a3a58e47bf3563cdb3e4b0edfab1de4d0e6b4
When formatting volumes, pass along fsType string which can be "auto"
to let the volume select the best choice. For now, private volumes
assume that MMC devices (like SD cards) are best off using f2fs when
both kernel support and tools are present, otherwise fall back to
ext4. Use blkid when mounting to pick the right set of tools.
Move filesystem utility methods into namespaces and place in separate
directory to be more organized.
Bug: 20275581
Change-Id: Id5f82d8672dda2e9f68c35b075f28232b0b55ed4
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
Sadly setexeccon() is process global, so we need to carefully ensure
that all exec() are mutually exclusive to avoid transitioning into
unwanted domains. Also, because we have several threads floating
around, we need to guard all our FDs with O_CLOEXEC.
Format all newly created volumes immediately after partitioning,
but silence all events emitted from those volumes to prevent the
framework from getting all excited. Unify all notify events under a
single codepath to make them easy to silence.
Sent SIGINT before escalating to SIGTERM when unmounting.
Bug: 19993667
Change-Id: Idc6c806afc7919a004a93e2240b42884f6b52d6b
Mount private volumes at /mnt/expand, which is where we have new
SELinux policy waiting for us. Also ensure that foundational
directories are ready when mounting.
Create local fs_prepare_dir() wrapper that sets SELinux context
based on path, avoiding the need for a later restorecon.
Use UUID as directory name for public volumes. Wait a few seconds
before issuing first signal when force unmounting.
Bug: 19993667
Change-Id: If22595380faaae321705b06c87d877419620da48
vold works with two broad classes of block devices: untrusted devices
that come in from the wild, and trusted devices like PrivateVolume
which are encrypted.
When running blkid and fsck, we pick which SELinux execution domain
to use based on which class the device belongs to.
Bug: 19993667
Change-Id: I2695f028710a4863f0c3b2ed6da437f466401272
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
