[Multi-user][Android] User data get deleted and lost, device reset

EDIT: New experiments conduct to a better description, more precision, more reproductibility

REPRODUCIBILITY: 83 % (5 times of 6 tries)
OS VERSION: 4.4.0.58 Licenced
HARDWARE: XA2 Dual SIM
UI LANGUAGE: UK EN
REGRESSION: ?

DESCRIPTION:

When using multi-user (2 users), data from one user gets suddenly totally deleted and phone goes to “Ahoj” first-boot-welcome-screen → Licence-acceptation-screen loop, leaving the user’s dir emptied, excepted [see post’s bottom]
This happens when starting (and?/or) stopping Android support and changing user right after.

PRECONDITIONS:

Set up two users,
Use the primary for Android things
Use the second user for daily use (android not available)

STEPS TO REPRODUCE:

  1. Go to primary user “Device Owner”
  2. Start or Stop (not sure which one, maybe both) Android Support
  3. Switch to secondary user and log in.

EXPECTED RESULT:

Log as secondary user.

ACTUAL RESULT:

“Ahoj” first-boot-welcome-screen → Licence-acceptation-screen loop. User data deleted.

MODIFICATIONS:

Storeman, Chum, Patchmanager (plain text mail, call autorec, lockscreen torch/mute),
Increased the user disk space allowed. Description here.
Allowed secondary call recordings. Description here

ADDITIONAL INFORMATION:

Long to build details list: Time consuming experiments because a reflash (dd part. 0p76) is needed each time.
Noticed:

  • The case does not occur if I uninstall and reinstall PatchManager
  • Seems not to occur either, if I try to enable debug symbols on home partition, even w/o downloading necessary packages and come back to settings.

Also interesting to note that the reset sometimes happen
-when changing from defaultuser to additional user
or, if not happened.
-when coming back to defaultuser from additional user.
Deleting -I believe- only the user’s data that was tried to log in at the “Ahoj” moment.

List of user's dir remaining files

Files found with recovery mode in the user’s dir after the bug occured and licence-acceptation-screen was accepted.

/home/defaultuser/.local
/home/defaultuser/.local/share
/home/defaultuser/.local/share/system
/home/defaultuser/.local/share/system/privileged
/home/defaultuser/.local/share/system/privileged/Secrets
/home/defaultuser/.local/share/system/privileged/Secrets/org.sailfishos.secrets.plugin.storage.sqlite
/home/defaultuser/.local/share/system/privileged/Secrets/org.sailfishos.secrets.plugin.storage.sqlite/secrets.db
/home/defaultuser/.local/share/system/privileged/Secrets/org.sailfishos.secrets.plugin.storage.sqlite/secrets.db-wal
/home/defaultuser/.local/share/system/privileged/Secrets/org.sailfishos.secrets.plugin.storage.sqlite/metadata.db-shm
/home/defaultuser/.local/share/system/privileged/Secrets/org.sailfishos.secrets.plugin.storage.sqlite/metadata.db-wal
/home/defaultuser/.local/share/system/privileged/Secrets/org.sailfishos.secrets.plugin.storage.sqlite/secrets.db-shm
/home/defaultuser/.local/share/system/privileged/Secrets/org.sailfishos.secrets.plugin.storage.sqlite/metadata.db
/home/defaultuser/.local/share/system/privileged/Secrets/org.sailfishos.secrets.plugin.encryptedstorage.sqlcipher
/home/defaultuser/.local/share/system/privileged/Secrets/org.sailfishos.secrets.plugin.encryptedstorage.sqlcipher/metadata.db-shm
/home/defaultuser/.local/share/system/privileged/Secrets/org.sailfishos.secrets.plugin.encryptedstorage.sqlcipher/metadata.db-wal
/home/defaultuser/.local/share/system/privileged/Secrets/org.sailfishos.secrets.plugin.encryptedstorage.sqlcipher/metadata.db
/home/defaultuser/.local/share/system/privileged/Secrets/initialsalt
/home/defaultuser/.local/share/system/privileged/Secrets/initialsalt/4c74c272-b47a-4488-a425-f0961fa00698
/home/defaultuser/.local/share/system/privileged/Secrets/initialsalt/4c74c272-b47a-4488-a425-f0961fa00698/file1
/home/defaultuser/.local/share/system/privileged/Secrets/initialsalt/4c74c272-b47a-4488-a425-f0961fa00698/file2
/home/defaultuser/.local/share/system/privileged/Secrets/initialsalt/4c74c272-b47a-4488-a425-f0961fa00698/file0
/home/defaultuser/.local/share/system/privileged/Secrets/lockcodecheck
/home/defaultuser/.local/share/system/privileged/Secrets/lockcodecheck/ed61657e-973d-4b5e-8d51-e2fd2b6b098c
/home/defaultuser/.local/share/system/privileged/Secrets/lockcodecheck/ed61657e-973d-4b5e-8d51-e2fd2b6b098c/file1
/home/defaultuser/.local/share/system/privileged/Secrets/lockcodecheck/ed61657e-973d-4b5e-8d51-e2fd2b6b098c/file2
/home/defaultuser/.local/share/system/privileged/Secrets/lockcodecheck/ed61657e-973d-4b5e-8d51-e2fd2b6b098c/file0
/home/defaultuser/.local/share/system/privileged/connman-vpn
/home/defaultuser/.local/share/system/privileged/connman
/home/defaultuser/.local/share/system/privileged/connman/settings
/home/defaultuser/android_storage

2 Likes

Your second user, the non-default one, which UID does that have assigned? Is it greater than 100000?

yes, it was 100001.
20 char

Thanks.

While I don’t think it does, I really would like to rule out that patchmanager has anything to do with it.

You wouldn’t have a testing device where you could try to reproduce without PM installed would you?

Made new experiments with secondary phone.
I can easily reproduce now.
Updated first post.

So.
I dd-restored part. 0p76 (from licensed phone to a not licensed one) twice to try reproduce. It did the reset/data loss.
I uninstalled PM then couldn’t reproduce. Reinstalled with same patches, reboot, try: still couldn’t reproduce.
But it is possible that Alien Dalvik is not acting the same way any more after un-installing PM, as I went online.
Doing this, AD may have noticed it was on an unlicensed device.
But it acted the same in settings AD page: starting…stopping…starting…

To be continued when I have (much) more time…

Thank you very much for your efforts.

We will look into where PM may come into play here, maybe there is some problem with the UID detection code of the library.

I have created https://github.com/sailfishos-patches/patchmanager/issues/311 for this.

1 Like

The issue occured to me once, just after installing the phone, without anything additional installed or tuned, but after I transfered via rsync all data from the old phone to the new one.

I created a second user, and then switched back to the main one. When doing so, it never succeeded and I ended up to the welcome page where you should choose your language. Then it spinned forever. Mounting the home in recovery, I noticed that my home had been wiped out and a new one had been created with root:root permissions which made the phone unable to boot.

I must admit that it took me so much time to fix the issue and rsync again that I didn’t dare to switch user again to see if it’s reproducible or to try to find the issue… So a not very useful post, just to mentioned that you are not alone with this issue. I admire your dedication though to try to find the proper reproducer !

2 Likes

Thank you both for your encouragements!

[OT]
Despite it really makes me tired when this reset happens, Multi-User is really the perfect solution for a privacy in conjunction with Android user.
Without separating users, there is no real privacy with Android IMO.
Android is liquid and leaks in a lot of places in the phone (or makes datas to leak into it).
To be more strictly verified but IIRC, I found some of my data into:

/home/.android/data/data/com.android.providers.contacts/databases/profile.db
/home/.android/data/data/com.android.providers.calendar/databases/calendar.db
/home/.android/data/user_de/0/com.android.providers.telephony/databases/telephony.db
/home/.android/data/data/com.google.android.gms/databases/pluscontacts.db

And probably other places.
My belief is that authorisations don’t really protect against data theft.
As I have no time and competences to verify my beliefs, scan all the FS and sniff all the traffic, Multi-User is perfect for me.
[/OT]

I thought I’coul’d try multi-user once again, without PM.
But if you @dcaliste say it happaned to you also without PM installed, I think I’ll reconsider the question and maybe live without Android…
@nephros, I keep my second phone ready. If there is a modified version of PM you’d like me to try, just say!

Lovely, thank you! Hopefully (for PM) nothing will come of it though.

Really wierd!
If I

  • Restore the rootfs and home (dev/mmcblk0p76)with dd
  • Boot, log in Device Owner (defaultuser)
  • Start Android Support
  • Log out/in to secondary user

I get nuked, “Ahoj”, reset. 100% (4 of 4 tries)

I I uninstall PatchManager before the above steps, I couldn’t reproduce.
But if I reinstall PM and re-enable patches, even reboot, I am still not able to reproduce.

Wierd.

The same if I enable debug symbols on home partition

1 Like

Some dd later…
No, more I try, more I think it is not PM related.
Even if I just try enabling debug symbols on home partition without to go online to get the packages, and come back to settings, the problem doesn’t occurs anymore.
Some fragile bug stuck somewhere seems easily to make fall and disapear…

1 Like

Details added in paragraph “Modifications”

1 Like

Thanks for the super-detailed report and investigation @ric9k. I’ve created an internal bug report about this and tagged it as “tracked”.

Can I please double-check that you ruled out PatchManager as a factor? That’s what I understood from reading through, but there’s still a fragment of doubt in my mind that it would be helpful to clear up.

One thing to add:

There have been versions of MyBackup which have a bug in the RPM uninstall script where it literally does a rm -rf ~.

While I can’t see how this would trigger through a user switch, have any of you that were affected had MyBackup installed?

Unfortunately, I don’t remember much more than what I wrote.
But when it happened, I didn’t touch anything in PM before.

Perhaps interresting for you:
I still have the disk image of the system just before nuke happens.
I can restore it and be able to reproduce.
If you indicate me a way to log everything happening into the phone, I could try and report.

1 Like

Indeed, I have MyBackup installed. (but finally never used)
Also here, I could delete the concerned file (the one containing rm -f) and try to reproduce.

Or, to avoid changing too much things, I could temporarly rename the rm command, prior to try reproducing…

For general debugging, I guess the Jolla team must answer that.

For the patchmanager preload library there is the enviromnent variable PM_PRELOAD_DEBUG which makes it verbose (but will log to stdout/stderr which would need to be captured).

For the daemon there is /var/lib/environment/patchmanager/10-dbus.conf where you can set the debug environment to true and restart the service.

Enabling persistent journal would be the first step for sure.

1 Like

Re: MyBackup you can’t edit the script because it’s in the rpm file.
And busybox rm is a symlink to busybox itself, or a builtin, so no moving it out of the way either.

But if it is uninstalled and triggers the rm there should be some output in /var/log/zypp/history, I expect lots of permission denied messages.

But actually the MyBackup bug should nuke the whole system, not just home, so it’s probably unrelated.

1 Like