On Tue, Mar 17, 2020 at 11:01 AM andythe_great <andythe_great@protonmail.com> wrote:
Hello,
Systemd 245 was released with support for systemd-homed.
https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg43629.ht...
There are many interesting features about encryption as well. If I understand correctly, the systemd-homed can encrypt individual home directory and does not need normal full disk encryption that has been normally done. Could this solve typing password twice when decrypting disk on default setup as well?
Will openSUSE use systemd-homed?
I've been evaluating it and I like the concept. The simplest option openSUSE could consider is the --storage=subvolume type, which does no encryption on its own. This can be combined with or without full disk encryption (via LUKS), and still gain the authentication benefits. integration would be fairly straightforward I think, because there's no complex issues surrounding storage management. Whereas with LUKS encrypted loop mounted files, it gets tricky in the multiuser case. A fallocated file used per ~/ ensures sane file system free and used space reporting. But as soon as you want to create a new user, what if the underlying storage is nearly full? Well now you need a policy and logic to handle shrinking one user home, before creating another, and possibly even keeping them balanced out or otherwise offering UI to do this in, e.g. a Users panel where you'd create these new users. Tricky. systemd-homed does have a resize subcommand and can handle resizing Btrfs, which of course supports shrink while mounted. But it doesn't yet offer any kind of policy or logic to manage free space which is functionally separated because the host file system is separate from that of each user home file system. OK so one solution to this problem is the sparse file for backing, which is also supported. Now you don't need to shrink file systems, they can just be fstrimed to return their unused blocks to the underlying storage. But now the problem is, you can think provision the storage in such a way that a user home suggests more space is available than the free space on the underlying storage. If the underlying storage runs out of space, it's ENOSPC, but in the user home this becomes EIO. And the EIO handling of apps isn't always the most graceful. OK let's say all the user homes are sparse files. And let's say at login time, systemd-home were to check free space on underlying storage, and resize the user home file system such that it has that same amount of free space? Or 85% of it? That might be sane. A more sophisticated check, would be a low water mark on the underlying storage, and if that's triggered, then immediately resize (shrink) the user home to reflect actual available space. I suspect such logic should go into systemd-homed as enhancements, rather than going in the desktop environment. The nice thing about Btrfs is that it's explicitly designed for fs resize. It can resize all day long and doesn't care. There's no locality impact. Whereas this isn't the case with ext4 and XFS. The resize code leverages balance code, and also comes into play with multiple device support. Another possibility to consider is native Btrfs encryption. I haven't seen anything about it on linux-btrfs@ list for a while (year?). -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org