It's essential that files created by vold get the correct SELinux
labels, so make sure to check for errors when setting them.
ENOENT (no label defined) is expected on some files such as
/mnt/appfuse/*, so allow ENOENT but log a DEBUG message.
This will help debug b/269567270. This is not a fix for b/269567270.
Bug: 269567270
Test: Created user and checked SELinux labels of user's directories
Test: atest CtsBlobStoreHostTestCases
Change-Id: Ife005bdd896952653943c57336deb33456f7c5d8
It's essential that files created by vold get the correct SELinux
labels, so make sure to check for errors when setting them.
This will help debug b/269567270. This is not a fix for b/269567270.
Bug: 269567270
Test: Created user and checked SELinux labels of user's directories
Change-Id: I99e4d530a00f9401532c9cb0990df254b7a12a80
Due to frameworks/base commit 5c65b1ee1023 ("Don't prepare CE storage on
user creation") (http://ag/20241697), removing a user immediately after
creating it causes the user's directories to be destroyed before CE
storage was prepared.
Functionally this works fine; however, it causes some error messages to
be spammed to the log because 'vold_prepare_subdirs destroy' doesn't
like that /data/misc_ce/$userId and /data/vendor_ce/$userId don't exist.
vold_prepare_subdirs logs two error messages itself, but it also exits
with a failure status, which bubbles up and causes a Slog.wtf with a
stack trace in StorageManagerService.
Fix this by making rmrf_contents() simply return true if the directory
doesn't exist.
Bug: 232452368
Test: 'pm create-user 10 && pm remove-user 10' and check logcat
Change-Id: I867a915f4b25e1a5f0603fbd84680b673ff5eb96
There is a race condition between key eviction and killing user
processes. The race condition is difficult to properly fix without
significantly degrading UI performance.
If the race condition occurs, decrypted filesystem data is left in
various kernel caches. To mitigate, we try to ensure the caches are
flushed by evicting the keys again in a worker thread.
Test: Checked that the correct log messages appear when evicting a
user's keys
Bug: 140762419
Change-Id: I9e39e5bb0f5190284552bcd252b6213a22a51e91
Some devices isolate CPUs under low battery. It causes
low performance and 5 sec timeout is soemtimes too short
for dm device ready.
Bug: 267989884
Change-Id: I52e1140b961ac42401a409e3264a5facc0f60cc4
Signed-off-by: Masaya Takahashi <masaya.a.takahashi@sony.com>
This reverts commit 564f6c649a.
Reason for revert: Un-backporting.
Note: This is not a direct revert. We should keep the minor refactoring
in PublicVolume.cpp; no point making the code worse.
Test: Revert.
Change-Id: Ic03ed25ad15a2da974921542a20cd27224347f68
This CR, when paired with a functional NTFS implementation and the
corresponding SEPolicy updates, will allow NTFS USB drives to be mounted
on Android.
Bug: 254407246
Test: Extensive testing with an ADT-4 and NTFS USB drives.
Merged-In: If4197c4c588866c611cd6ba3483707d3cb0e0cf8
Change-Id: If4197c4c588866c611cd6ba3483707d3cb0e0cf8
We should not delete keys, once the first one was created.
Bug: 197782466
Change-Id: Ia895c140aa16553b422748531b01931737a0ea94
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
When userdata partition is the type of ext4, checkpoint and metadata
encryption are enabled, boot up the images, if the slot currently
in use is not marked as "successful" and userdata is wiped, a reboot
will be triggered because of "Checkpoint commit failed"
In this patch, do not create checkpoint when the preceding condition
occurs, otherwise "dm-default-key" sits below "dm-bow".
Because cp_needsCheckpoint(), cp_prepareCheckpoint() and cp_commitChanges()
are always executed when the system boots up, and now there is a condition
that BOW device is not created while the slot in use is not marked as
"successful", set "isBow" to be "false" if BOW state fails to be set to
1, if "isBow" is false, then there is no need to commit the checkpoint,
and the system won't automatically reboot.
Bug: 193457319
Test: i.MX 8M Plus EVK, images flashed to board, misc and userdata
partitions are wiped, checkpoint and metadata encryption are
enabled for ext4 userdata partition.
Signed-off-by: faqiang.zhu <faqiang.zhu@nxp.com>
Change-Id: I4ad47a9504f1be0407f0fd196001a0e96919be33
If a service doesn't specify any capabilities in it's definition in the
.rc file, then it will inherit all the capabilities from the init.
Although whether a process can use capabilities is actually controlled
by selinux (so inheriting all the init capabilities is not actually a
security vulnerability), it's better for defense-in-depth and just
bookkeeping to explicitly specify the capabilities that vold needs.
The list of capabilities that vold is allowed to use was obtained via:
```
$ adb pull /sys/fs/selinux/policy /tmp/selinux.policy
$ sesearch --allow -s vold -c capability,capability2 /tmp/selinux.policy
allow vold vold:capability { chown dac_override dac_read_search fowner fsetid kill mknod net_admin sys_admin sys_chroot sys_nice sys_ptrace };
allow vold vold:capability2 block_suspend
```
In addition, since vold execs the /system/bin/sdcard, which transitions
into sdcardd domain, we also need to add capabilities that are required
by /system/bin/sdcard:
```
sesearch --allow -s sdcardd -c capability,capability2 /tmp/selinux.policy
allow sdcardd sdcardd:capability { dac_override dac_read_search setgid setuid sys_admin sys_resource };
```
vold can also transform into the following domains which don't seem to
need any capabilities: blkid, blkid_untrusted, fsck, fsck_untrusted
vold can also transform into sgdisk domain, which only needs
CAP_SYS_ADMIN:
```
sesearch --allow -s sgdisk -c capability,capability2 /tmp/selinux.policy
allow sgdisk sgdisk:capability sys_admin
```
Bug: 249796710
Test: device boots
Test: prebumit
Change-Id: Ic2a35fd62d6ed8c7b305c23607e6c24b197cf6bc
sleep may exit early due to interupts.
This ensures the full expected time elapses before timing out.
Bug: 258348748
Test: Mount removable storage with ~30K folders,
observe timeout in logs
Change-Id: I8092d4be43b85c9a53e8bb2658316159ab93bfc2
Allows for easy override of fuse-bpf for testing without a rebuild
Test: Set this property with ro.fuse.bpf.enabled both true and false
Make sure ro.fuse.bpf.is_running is expected result
Bug: 219958836
Change-Id: I589511ea5cda76db1d55bdc2124fb546907d8acd
s_running flag signals to tests whether fuse-bpf is running
Test: Builds, runs, ro.fuse.bpf.is_running is correct, fuse-bpf works
Bug: 202785178
Change-Id: I2b967567092da2fab90e44c44ff2e51b372b85ed
DM_DEV_CREATE no longer creates sysfs nodes as of Linux kernel 5.15. It
is now necessary to DM_TABLE_LOAD as well.
Bug: 259328366
Test: userdata mounts
Change-Id: I0f88afdf95a97d44eb365e4302bbfdc7c28c0bcb
With the way the FUSE mount point are currently setup for emulated
volumes, there can be multiple paths that serve the same files on the
lower filesystem; eg
* /mnt/user/0/emulated/0/Android
* /mnt/user/10/emulated/0/Android
both refer to the same file on the lower filesystem:
* /data/media/0/Android
this is normally not a problem, because cross-user file access is not
allowed, and so the FUSE daemon won't serve files for other users.
With clone profiles this is no longer true however, as their volumes
are accessible by each other.
So, it can happen that an app running in clone profile 10 accesses
"/mnt/user/10/emulated/0/Android", which would be served by the FUSE
daemon for the user 10 filesystem.
At the same time, an app running in the owner profile 0 accesses
"mnt/user/0/emulated/0/Android", which would be served by the FUSE
daemon for the user 0 filesystem.
This can cause page cache inconsistencies, because multiple FUSE daemons
can be running on top of the same entries in the lower filesystem.
To prevent this, use bind mounts to make sure that cross-profile
accesses actually end up in the FUSE daemon to which the volume
belongs: "/mnt/user/10/emulated/0" is bind-mounted to
"/mnt/user/0/emulated/0", and vice-versa.
Bug: 228271997
Test: manual
Change-Id: Iefcbc813670628b329a1a5d408b6126b84991e09
retrieveKey can fail in load_all_de_keys if a user
is partially removed, i.e. cases where
fscrypt_destroy_user_key() got interrupted. So just
ignore the failure, else could reboot into recovery.
Test: pm create-user foo
pm remove-user 10
adb reboot && check device not enter recovery
Signed-off-by: liulvping <liulvping@xiaomi.com>
Change-Id: Iba9d53a0833524d00e65d0427ab03002c5d8d509
When running on kernel without FUSE, fs::directory_iterator
throws exception since /sys/fs/fuse/connections is missing.
This patch uses non-throwing fs::directory_iterator
and adds explicit error check.
Test: vold doesn't fail with FUSE disabled
Signed-off-by: Oleg Lyovin <ovlevin@sberdevices.ru>
Change-Id: I51b68363edf75033fcec3ce5623f419d5a68c991
As a small optimization and code simplification, stop reading and
writing the "stretching" file alongside each stored key. vold never
does key stretching anymore.
There was one special case in the code where if the stretching file
existed and contained "nopassword", then the secret was ignored.
However, this didn't seem to be of any use, especially since it didn't
cause Keystore to be used, so it did *not* allow a key stored with no
secret to be read if a secret was unexpectedly provided.
Bug: 232452368
Bug: 251131631
Bug: 251147505
Change-Id: I5a7cbba7492526e51c451f222b9413d9fae6bce5
Storage keys that are encrypted by the user's synthetic password don't
need to be securely deletable by vold, since secure deletion is already
implemented at a higher level: the synthetic password protectors managed
by LockSettingsService. Therefore, remove the use of the secdiscardable
file by vold in this case to improve performance.
Bug: 232452368
Bug: 251131631
Bug: 251147505
Change-Id: I847d6cd3b289dbeb1ca2760d6e261a78c179cad0
