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

[Boyce, Kevin P [US] (AS)]

Just curious how this works with automount and instances where the user's home directory location has to be looked via an ldap query, resolved, and nfs mounted.

Is systemd-homed meant to replace automount's function, or is it only for users have locally encrypted home directories with LUKS?

Kevin

-----Original Message-----
From: systemd-devel <systemd-devel-bounces at lists.freedesktop.org> On Behalf Of Lennart Poettering
Sent: Friday, September 27, 2019 5:44 AM
To: Jörg Kastning <joerg.kastning at gmail.com>
Cc: systemd-devel at lists.freedesktop.org
Subject: EXT :Re: [systemd-devel] How does the mount process of systemd-homed work?

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
_______________________________________________
systemd-devel mailing list
systemd-devel at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel