Since installers can create directories in Android/obb, make sure those
directories end up with the correct ACL bits as well.
Bug: 146419093
Test: inspect filesystem manually
Change-Id: I211e921197560a40599938463f3171a0ff92d9aa
We want subdirectories of Android/data, Android/obb etc. to
automatically maintain their group-id.
Bug: 146419093
Test: manual inspection of /sdcard/Android
Change-Id: I36883febb01aa155dfafb0e86f8b99223cde9815
For some reason this can be racy; until we understand the root cause,
retry to unblock AdoptableHostTest.
Bug: 149396179
Test: atest AdoptableHostTest no longer hangs
Change-Id: I162ff8ad305535e7a4fab3d88f38b687b50cf4a3
More consistency between MetadataCrypt and cryptfs, and steps towards
supporting Adiantum properly in MetadataCrypt.
Test: create private volume on Cuttlefish
Bug: 147814592
Change-Id: Ic3993c1fde11b4f5a9e6cc8ee588a7d92241c6ab
Initially, we were thinking to pass kInternal for non usb drive/sd card
drive (for local external storage like directory shared from ChromeOS).
Fortunately, the DocumentsUI logic apparently has TYPE_LOCAL with
R.drawable.ic_root_smartphone (that is overlayable) for external storage
other than TYPE_USB and TYPE_SD.
Therefore, instead of creating a kInternal flags, we can just passed kUsb
and kSd and not passing anything for "internal external storage" - which
will render ic_root_usb, ic_root_sd, and ic_root_smartphone as icons
accordingly. And since ic_root_smartphone is already overlayable, we
could overlayed in /vendor - which effectively is what we initially
wanted when thinking of introducing kInternal flag.
Bug: 132796154
Test: Customize flags in /vendor for different devices and DocumentsUI
shows the ic_root_smartphone (which can be overlayed) when kUsb is not
passed, and USB icon when kUsb is passed.
Change-Id: I55f13e214bbb2aeed96b6950bcf391121174c354
This was hard to read and understand. Instead, fall back to explicit
string operations with more comments on what we're doing and what we're
allowing.
This also fixes an issue where apps were asking us to create dirs on
their behalf that our more than 2 levels deep, eg
com.foo/files/downloads ; I thought such paths weren't allowed, but
apparently they are (and there's no good reason for us to not set them
up correctly).
Bug: 149407572
Test: launch opera
Change-Id: I7c64831032b66e90960b96e41ee42c7d616a759c
For some reason this can be racy; until we understand the root cause,
retry to unblock presubmit.
Bug: 149396179
Test: atest AdoptableHostTest no longer hangs
Change-Id: I3fb4f1d966172bac2f6c52d41c4564f905765212
Abolish cryptfs_revert_ext_volume, handle in caller. This allows us to
use DeleteDeviceIfExists, avoiding a spurious error message.
Test: create private volume on Cuttlefish, eject, check logs
Bug: 147814592
Change-Id: I836d8bd11b29e32da0863aaa75144543bb9cab9c
Not for security, but for consistency with the way we handle other
keys, and to move the length check to where it belongs.
Test: create private volume on Cuttlefish
Bug: 147814592
Change-Id: I10fc4896183d050ce25ff174faf78f525cf62930
To prevent keys from being compromised if an attacker
acquires read access to kernel memory, some inline
encryption hardware supports protecting the keys in
hardware without software having access to or the
ability to set the plaintext keys. Instead, software
only sees "wrapped keys", which may differ on every boot.
'wrappedkey_v0' fileencryption flag is used to denote
that the device supports inline encryption hardware that
supports this feature. On such devices keymaster is used
to generate keys with STORAGE_KEY tag and export a
per-boot ephemerally wrapped storage key to install it in
the kernel.
The wrapped key framework in the linux kernel ensures the
wrapped key is provided to the inline encryption hardware
where it is unwrapped and the file contents key is derived
to encrypt contents without revealing the plaintext key in
the clear.
Test: FBE validation with Fscrypt v2 + inline crypt + wrapped
key changes kernel.
Bug: 147733587
Change-Id: I1f0de61b56534ec1df9baef075acb74bacd00758
We directly pass a reference to our std::string, instead of
forcing the creation of a temporary std::string from the
result of c_str().
Test: TreeHugger
Change-Id: Ibab13f1e1ff43af076df60ae4032bf9dd111dd27
* changes:
Set quota project ID and inheritance on top-level storage directory.
Set default ACL on application-specific directories.
Use a regex to create application directories.
When creating external storage directories like /data/media/0, make sure
we set the quota project ID correctly, and enable project ID
inheritance. This ensures that all directories/files under this will be
created with the correct project ID and inheritance as well.
Bug: 146419093
Test: lsattr -p on /data/media
Change-Id: I32bfced0d67eb8c1865897b085324f00c55926a0
On devices without sdcardfs, application-specific directories have a
particular GID that ensure some privileged daemons (like installers) are
able to write to them. Android applications however run with a umask of 0077, which means that
any subdirectory they create within their app-specific directory has
mode 700, which in turn prevents things like DownloadManager from
working, since it can be asked to download into a subdir of the app's
private storage.
To prevent this from happening, set a default 770 ACL on the top-level
app-specific directory (eg, /data/media/0/Android/data/com.foo); the
effect of that default ACL is that all directories that are created
within these directories automatically get a 770 mask, regardless of the
umask that the process has.
Bug: 146419093
Test: atest FuseDaemonHostTest on cf_x86 (without sdcardfs)
Change-Id: I3178694e6d25ce3d04a0918ac66862f644635704
StubVolume is a volume type for ARC++ external storage. Named StubVolume
because it is managed from outside Android (not through Android kernel).
Previously, StubVolume is a diskless volume. However, as mentioned in
jsharkey@ email, a disk is needed for StubVolume to hold "kInternal"
(external storage type that is "external" from Android perspective,
but is "internal" to the device. For example shared directory from
ChromeOS to Android) and "kIndexable" (whether or not a disk should be
indexed by MediaStore).
The addition of disk means we could expose the createStubVolume API to
add a disk flags, which is also introduced in this CL.
Both kInternal and kIndexable will be introduced in separate CL.
Bug: 132796154
Test: Mount/unmount ARC++ removable device in ChromeOS.
Change-Id: I8b77fa1cf50ab38a2892272154dafdb78f079378
