Am 05.12.19 um 13:32 schrieb Lennart
Poettering:
That depends on what you have chosen "sleep" or "hibernate" .Well, the way this has been traditionally done is that the lock screen is displayed by a program running under the user's identity and that the user's data is entirely unlocked the entire time during suspend,
If the device just sleeps, your data is unprotected, as the key could be in your still powered memory bank.
With hibernation, as far as I have seen it with my devices, the hw stops entirely after saving the memory state to disk,
an encrypted disk I may add. On boot, it asks for the decryption keys as it would normally do, finds the hibernate signature
on swap ( i presume / which is also encrypted ) and restores memory. I don't see a way for an attack here.
I think your approach is not to the full extent of all possible user data locations. Some examples:
/var/lib/mysql MariaDB SQL Database ( required i.e. by MythTV )
/var/www/ Apache Webserver ( required i.e. by RoundCube, BackupPC or Gnome User-Share )
if those aren't common enough, this will be:
/media/ Additional Storage Drives
It's quite common to have additional storage space on a desktop pc, which do not exactly extend /home/ space, more general space. If you have more than one "user" on a system, you can't mount it into /home/username/path as of the rights management.
When I had to estimate my system, it's a hundred GB in /home/ against a few TB != /home . Anyone who as ever bought a second drive for his/her/it pc , will face this problem, or has to learn to use LVM. I don't think it will work for the majority of userbase. It will only work for simple cases.
best regards,
Marius
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx