Mailinglist Archive: opensuse-factory (355 mails)

< Previous Next >
Re: [opensuse-factory] Will openSUSE adopt systemd-homed?
On Tue, Mar 17, 2020 at 11:01 AM andythe_great
<andythe_great@xxxxxxxxxxxxxx> wrote:

Hello,

Systemd 245 was released with support for systemd-homed.

https://www.mail-archive.com/systemd-devel@xxxxxxxxxxxxxxxxxxxxx/msg43629.html

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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
References