[systemd-devel] How does the mount process of systemd-homed work?

Lennart Poettering lennart at poettering.net
Fri Sep 27 09:44:21 UTC 2019


On Di, 24.09.19 19:16, Jörg Kastning (joerg.kastning at gmail.com) wrote:

> Hello to Lennart and this list,
>
> I watched the recording of Lennarts talk at the All Systems Go (
> https://cfp.all-systems-go.io/ASG2019/talk/VSQRXA/) and would like to ask
> some questions about the new way to process user home directoties and
> authentication.
>
> In the talk was said that the user does log in and systemd-homed.service
> mounts the user home directory as a LUKS loop back device which contains
> the '.identity' file with all the user information in the JSON struct,
> right?
>
> Isn't there a chicken egg problem? When all the user Information are stored
> in an encrypted LUKS file how should the user be able to login? Could
> someone explain this to me and may give an example, please?

Ultimately we keep three copies of the JSON identity record: one in
$HOME itself. (Why? Simply because we want to support other backends
too, besides the LUKS one, including plain dirs, where this is the
only reasonable place to put it). One in the LUKS2 header,
encrypted. (Why? Because we need to validate the record before
mounting the fs, and checks sigs and stuff, since mounting a kernel
file system is potentially dangerous, and we thus need to establish
trust first, before we could access $HOME). And finally, one copy on
the host. (This is created after first login only, and is kept there
so that we have certain metadata available without the user being
logged in, for example the name and pic for a face browser if that's
desired).

On login, these three copies are compared, and the newest one
picked. Since the records are each signed (and thus must come from the
single same source that has the private key to sign them with) it's
always clear which one that is. The newest version is the propagate to
the other instances that have older records.

> Lennart said there is plenty of documentation about the JSON struct. I
> didn't find any on the Internet. Could you please point my nose to
> it?

It's in the slides: there's a branch on github. Just follow that link,
there's plenty docs there.

> In the JSON file was a section for the users groups. Does the users get the
> same groups on every system they login to? Is there any way a user could be
> in different groups depending on the system where the user login to?

Yes, there's a "perMachine" section, that allows you to set certain
(not all!) settings per system. This is particularly relevant for
resource management settings, since those don't really make sense
outside of the context of a specific system. i.e. if you have a beefy
multi-cpu machine then setting a CPU set mask is substantially
different from doing so on a minimal single cpu system, if you follow
what I mean.

> The JSON struct has a block for each system in the binding section
> containing uid and gid. Will systemd prevent that a new user is added with
> the same uid using useradd for example? Where does systemd stored this
> Information when the user's home is not mounted?

All users are registered in NSS. Since adduser/useradd check NSS
things should be safe (the same way as for LDAP users, too).

The copy of the user identity record that is kept on the host is
stored in /var/lib/systemd/home/<user>.identity.

Lennart

--
Lennart Poettering, Berlin


More information about the systemd-devel mailing list