- 08 Jul, 2015 1 commit
-
-
Jeff Sharkey authored
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
-
- 09 Jun, 2015 2 commits
-
-
Jeff Sharkey authored
This ensures that we have consistent SELinux policy in place before going any further, and it mirrors the way we restorecon /data when first mounted. Bug: 21121357 Change-Id: I2a7e3584ade655fe1fae8916cf54f9eae3a0f99d
-
Jeff Sharkey authored
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
-
- 24 Apr, 2015 1 commit
-
-
Jeff Sharkey authored
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
-
- 12 Apr, 2015 1 commit
-
-
Jeff Sharkey authored
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
-
- 11 Apr, 2015 1 commit
-
-
Jeff Sharkey authored
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
-
- 07 Apr, 2015 1 commit
-
-
Jeff Sharkey authored
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
-
- 01 Apr, 2015 1 commit
-
-
Jeff Sharkey authored
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
-