What Happens with the Guest profile if the battery is disconnected?

DollyRags

When Delete guest activity > enable is enabled and the phone is gracefully shut down or restarted, the guest profile is purged.

Does anyone know what happens to this profile if the phone has a non-graceful shutdown, for example, if the battery is physically disconnected? Is it cleared immediately after the phone is rebooted? After the owner is logged in? Left in limbo?
Is there some piece of ephemeral data needed to decrypt the profile which is never stored outside of RAM, ensuring the guest can't be recovered even if the phone is forcibly shutdown?

Hoping someone familiar with the inner workings could comment. @GrapheneOS

telemetry83

In the case of a non-graceful shutdown, a guest user is deleted during boot.

In the code, guest users are also called ephemeral. When a guest user is created, it is marked ephemeral:

https://github.com/GrapheneOS/platform_frameworks_base/blob/f1b93e035b68cbe2570cec966bee3ee5b3c5dc28/core/java/android/os/UserManager.java#L4559-L4561

During boot, the UserManagerService builds up the list of users available on the phone. While constructing this list, certain users (such as a lingering guest user) are marked for removal:

https://github.com/GrapheneOS/platform_frameworks_base/blob/f1b93e035b68cbe2570cec966bee3ee5b3c5dc28/services/core/java/com/android/server/pm/UserManagerService.java#L4671

An ephemeral user from the previous boot is marked as a partial user, which is the system's way of indicating it can be later removed.

https://github.com/GrapheneOS/platform_frameworks_base/blob/f1b93e035b68cbe2570cec966bee3ee5b3c5dc28/services/core/java/com/android/server/pm/UserManagerService.java#L1274

Later during boot, partial users are deleted:

https://github.com/GrapheneOS/platform_frameworks_base/blob/f1b93e035b68cbe2570cec966bee3ee5b3c5dc28/services/core/java/com/android/server/pm/UserManagerService.java#L997

For the RAM-only encryption key question, someone who better understands user key storage would need to comment. When a user's storage keys are created, the device-encrypted (DE) key for a guest user is intentionally not written to flash. It's kept in the kernel, as the code comment below describes.

https://github.com/GrapheneOS/platform_frameworks_base/blob/f1b93e035b68cbe2570cec966bee3ee5b3c5dc28/core/java/android/os/storage/StorageManager.java#L1640-L1663

I don't know what ultimately happens with the credential-encrypted (CE) key.

telemetry83

Much of the key management happens at a lower level in FsCrypt.cpp. That class has comments that mention avoiding storing keys (including the CE key) for ephemeral users:

https://github.com/GrapheneOS/platform_system_vold/blob/c8c5b56e8d6a60ae8755df2f505c7a63ccba8255/FsCrypt.cpp#L100-L101

https://github.com/GrapheneOS/platform_system_vold/blob/c8c5b56e8d6a60ae8755df2f505c7a63ccba8255/FsCrypt.cpp#L804

I can't say 100%, but there is clearly intentional logic at multiple layers to ensure a guest user's encryption keys are not written to disk. If that is true, it would not be possible to recover the guest account if the phone is turned off (gracefully or not). That conclusion comes with the caveat that it might be possible for a RAM-based attack to extract keys before the RAM becomes unreadable.