docs/USERDB_AND_DESKTOPS: format text

This commit is contained in:
hulkoba 2024-02-26 14:39:30 +01:00
parent a4fd4d9cd5
commit d85c8335ea
No known key found for this signature in database
GPG key ID: ACB6C4A3A4F2BE2F

View file

@ -9,15 +9,14 @@ SPDX-License-Identifier: LGPL-2.1-or-later
Starting with version 245, systemd supports a new subsystem Starting with version 245, systemd supports a new subsystem
[`systemd-homed.service`](https://www.freedesktop.org/software/systemd/man/systemd-homed.service.html) [`systemd-homed.service`](https://www.freedesktop.org/software/systemd/man/systemd-homed.service.html)
for managing regular ("human") users and their home directories. Along with it for managing regular ("human") users and their home directories.
a new concept `userdb` got merged that brings rich, extensible JSON user/group Along with it a new concept `userdb` got merged that brings rich, extensible JSON user/group
records, extending the classic UNIX/glibc NSS `struct passwd`/`struct group` records, extending the classic UNIX/glibc NSS `struct passwd`/`struct group` structures.
structures. Both additions are added in a fully backwards compatible way, Both additions are added in a fully backwards compatible way, accessible through `getpwnam()`/`getgrnam()`/… (i.e. libc NSS) and PAM as
accessible through `getpwnam()`/`getgrnam()`/… (i.e. libc NSS) and PAM as
usual, meaning that for basic support no changes in the upper layers of the usual, meaning that for basic support no changes in the upper layers of the
stack (in particular desktop environments, such as GNOME or KDE) have to be stack (in particular desktop environments, such as GNOME or KDE) have to be made.
made. However, for better support a number of changes to desktop environments However, for better support a number of changes to desktop environments are recommended.
are recommended. A few areas where that applies are discussed below. A few areas where that applies are discussed below.
Before reading on, please read up on the basic concepts, specifically: Before reading on, please read up on the basic concepts, specifically:
@ -30,18 +29,17 @@ Before reading on, please read up on the basic concepts, specifically:
One key feature of `systemd-homed` managed encrypted home directories is the One key feature of `systemd-homed` managed encrypted home directories is the
ability that access to them can be suspended automatically during system sleep, ability that access to them can be suspended automatically during system sleep,
removing any cryptographic key material from memory while doing so. This is removing any cryptographic key material from memory while doing so.
important in a world where most laptop users seldom shut down their computers This is important in a world where most laptop users seldom shut down their computers
but most of the time just suspend them instead. Previously, the encryption keys but most of the time just suspend them instead.
for the home directories remained in memory during system suspend, so that Previously, the encryption keys for the home directories remained in memory during system suspend, so that
sufficiently equipped attackers could read them from there and gain full access sufficiently equipped attackers could read them from there and gain full access to the device.
to the device. By removing the key material from memory before suspend, and By removing the key material from memory before suspend, and re-requesting it on resume this attack vector can be closed down effectively.
re-requesting it on resume this attack vector can be closed down effectively.
Supporting this mechanism requires support in the desktop environment, since Supporting this mechanism requires support in the desktop environment, since
the encryption keys (i.e. the user's login password) need to be reacquired on the encryption keys (i.e. the user's login password) need to be reacquired on
system resume, from a lock screen or similar. This lock screen must run in system resume, from a lock screen or similar.
system context, and cannot run in the user's own context, since otherwise it This lock screen must run in system context, and cannot run in the user's own context, since otherwise it
might end up accessing the home directory of the user even though access to it might end up accessing the home directory of the user even though access to it
is temporarily suspended and thus will hang if attempted. is temporarily suspended and thus will hang if attempted.
@ -49,91 +47,86 @@ It is suggested that desktop environments that implement lock screens run them
from system context, for example by switching back to the display manager, and from system context, for example by switching back to the display manager, and
only revert back to the session after re-authentication via this system lock only revert back to the session after re-authentication via this system lock
screen (re-authentication in this case refers to passing the user's login screen (re-authentication in this case refers to passing the user's login
credentials to the usual PAM authentication hooks). Or in other words, when credentials to the usual PAM authentication hooks).
going into system suspend it is recommended that GNOME Shell switches back to Or in other words, when going into system suspend it is recommended that GNOME Shell switches back to
the GNOME Display Manager login screen which now should double as screen lock, the GNOME Display Manager login screen which now should double as screen lock,
and only switches back to the shell's UI after the user re-authenticated there. and only switches back to the shell's UI after the user re-authenticated there.
Note that this change in behavior is a good idea in any case, and does not Note that this change in behavior is a good idea in any case, and does not
create any dependencies on `systemd-homed` or systemd-specific APIs. It's create any dependencies on `systemd-homed` or systemd-specific APIs.
simply a change of behavior regarding use of existing APIs, not a suggested It's simply a change of behavior regarding use of existing APIs, not a suggested hook-up to any new APIs.
hook-up to any new APIs.
A display manager which supports this kind of out-of-context screen lock A display manager which supports this kind of out-of-context screen lock
operation needs to inform systemd-homed about this so that systemd-homed knows operation needs to inform systemd-homed about this so that systemd-homed knows
that it is safe to suspend the user's home directory on suspend. This is done that it is safe to suspend the user's home directory on suspend.
via the `suspend=` argument to the This is done via the `suspend=` argument to the
[`pam_systemd_home`](https://www.freedesktop.org/software/systemd/man/pam_systemd_home.html) [`pam_systemd_home`](https://www.freedesktop.org/software/systemd/man/pam_systemd_home.html)
PAM module. A display manager should hence change its PAM stack configuration PAM module.
to set this parameter to on. `systemd-homed` will not suspend home directories A display manager should hence change its PAM stack configurationto set this parameter to on.
if there's at least one active session of the user that does not support `systemd-homed` will not suspend home directories if there's at least one active session of the user that does not support
suspending, as communicated via this parameter. suspending, as communicated via this parameter.
## User Management UIs ## User Management UIs
The rich user/group records `userdb` and `systemd-homed` support carry various The rich user/group records `userdb` and `systemd-homed` support carry various
fields of relevance to UIs that manage the local user database or parts fields of relevance to UIs that manage the local user database or parts thereof.
thereof. In particular, most of the metadata `accounts-daemon` (also see below) In particular, most of the metadata `accounts-daemon` (also see below)
supports is directly available in these JSON records. Hence it makes sense for supports is directly available in these JSON records.
any user management UI to expose them directly. Hence it makes sense for any user management UI to expose them directly.
`systemd-homed` exposes APIs to add, remove and make changes to local users via `systemd-homed` exposes APIs to add, remove and make changes to local users via
D-Bus, with full [polkit](https://www.freedesktop.org/software/polkit/docs/latest/) D-Bus, with full [polkit](https://www.freedesktop.org/software/polkit/docs/latest/) hook-up.
hook-up. On the command line this is exposed via the On the command line this is exposed via the `homectl` command. A graphical UI that exposes similar functionality would be
`homectl` command. A graphical UI that exposes similar functionality would be
very useful, exposing the various new account settings, and in particular very useful, exposing the various new account settings, and in particular
providing a stream-lined UI for enrolling new-style authentication tokens such providing a stream-lined UI for enrolling new-style authentication tokens such
as PKCS#11/YubiKey-style devices. (Ideally, if the user plugs in an as PKCS#11/YubiKey-style devices.
uninitialized YubiKey during operation it might be nice if the Desktop would (Ideally, if the user plugs in an uninitialized YubiKey during operation it might be nice if the Desktop would
automatically ask if a key pair shall be written to it and the local account be automatically ask if a key pair shall be written to it and the local account be
bound to it, `systemd-homed` provides enough YubiKey/PKCS#11 support to make bound to it, `systemd-homed` provides enough YubiKey/PKCS#11 support to make
this a reality today; except that it will not take care of token this a reality today; except that it will not take care of token
initialization). initialization).
A strong point of `systemd-homed` is per-user resource management. In A strong point of `systemd-homed` is per-user resource management.
particular disk space assignments are something that most likely should be In particular disk space assignments are something that most likely should be
exposed in a user management UI. Various metadata fields are supplied allowing exposed in a user management UI. Various metadata fields are supplied allowing
exposure of disk space assignment "slider" UI. Note however that the file system exposure of disk space assignment "slider" UI.
back-ends of `systemd-homed.service` have different feature sets. Specifically, Note however that the file system back-ends of `systemd-homed.service` have different feature sets.
only btrfs has online file system shrinking support, ext4 only offline file Specifically, only btrfs has online file system shrinking support, ext4 only offline file
system shrinking support, and xfs no shrinking support at all (all three file system shrinking support, and xfs no shrinking support at all (all three file
systems support online file system growing however). This means if the LUKS systems support online file system growing however).
back-end is used, disk space assignment cannot be instant for logged in users, This means if the LUKS back-end is used, disk space assignment cannot be instant for logged in users, unless btrfs is used.
unless btrfs is used.
Note that only `systemd-homed` provides an API for modifying/creating/deleting Note that only `systemd-homed` provides an API for modifying/creating/deleting users.
users. The generic `userdb` subsystem (which might have other back-ends, besides The generic `userdb` subsystem (which might have other back-ends, besides
`systemd-homed`, for example LDAP or Windows) exclusively provides a read-only `systemd-homed`, for example LDAP or Windows) exclusively provides a read-only interface.
interface. (This is unlikely to change, as the other back-ends might have very (This is unlikely to change, as the other back-ends might have very
different concepts of adding or modifying users, i.e. might not even have any different concepts of adding or modifying users, i.e. might not even have any local concept for that at all).
local concept for that at all). This means any user management UI that intends This means any user management UI that intends to change (and not just view) user accounts should talk directly to
to change (and not just view) user accounts should talk directly to
`systemd-homed` to make use of its features; there's no abstraction available `systemd-homed` to make use of its features; there's no abstraction available
to support other back-ends under the same API. to support other back-ends under the same API.
Unfortunately there's currently no documentation for the `systemd-homed` D-Bus Unfortunately there's currently no documentation for the `systemd-homed` D-Bus API.
API. Consider using the `homectl` sources as guidelines for implementing a user Consider using the `homectl` sources as guidelines for implementing a user management UI.
management UI. The JSON user/records are well documented however, see above, The JSON user/records are well documented however, see above,
and the D-Bus API provides limited introspection. and the D-Bus API provides limited introspection.
## Relationship to `accounts-daemon` ## Relationship to `accounts-daemon`
For a long time `accounts-daemon` has been included in Linux distributions For a long time `accounts-daemon` has been included in Linux distributions
providing richer user accounts. The functionality of this daemon overlaps in providing richer user accounts.
many areas with the functionality of `systemd-homed` or `userdb`, but there are The functionality of this daemon overlaps in many areas with the functionality of `systemd-homed` or `userdb`, but there are
systematic differences, which means that `systemd-homed` cannot replace systematic differences, which means that `systemd-homed` cannot replace
`accounts-daemon` fully. Most importantly: `accounts-daemon` provides `accounts-daemon` fully.
"side-car" metadata for *any* type of user account, while `systemd-homed` only Most importantly: `accounts-daemon` provides "side-car" metadata for *any* type of user account, while `systemd-homed` only
provides additional metadata for the users it defines itself. In other words: provides additional metadata for the users it defines itself.
`accounts-daemon` will augment foreign accounts; `systemd-homed` cannot be used In other words: `accounts-daemon` will augment foreign accounts; `systemd-homed` cannot be used
to augment users defined elsewhere, for example in LDAP or as classic to augment users defined elsewhere, for example in LDAP or as classic `/etc/passwd` records.
`/etc/passwd` records.
This probably means that for the time being, a user management UI (or other UI) This probably means that for the time being, a user management UI (or other UI)
that wants to support rich user records with compatibility with the status quo that wants to support rich user records with compatibility with the status quo
ante should probably talk to both `systemd-homed` and `accounts-daemon` at the ante should probably talk to both `systemd-homed` and `accounts-daemon` at the
same time, and ignore `accounts-daemon`'s records if `systemd-homed` defines same time, and ignore `accounts-daemon`'s records if `systemd-homed` defines them.
them. While I (Lennart) personally believe in the long run `systemd-homed` is While I (Lennart) personally believe in the long run `systemd-homed` is
the way to go for rich user records, any UI that wants to manage and support the way to go for rich user records, any UI that wants to manage and support
rich records for classic records has to support `accounts-daemon` in parallel rich records for classic records has to support `accounts-daemon` in parallel
for the time being. for the time being.
@ -145,17 +138,16 @@ probably be removed from the general stack, hence this sounds like a temporary
solution only. solution only.
In case you wonder, there's no automatic mechanism for converting existing In case you wonder, there's no automatic mechanism for converting existing
users registered in `/etc/passwd` or LDAP to users managed by users registered in `/etc/passwd` or LDAP to users managed by `systemd-homed`.
`systemd-homed`. There's documentation for doing this manually though, see There's documentation for doing this manually though, see
[Converting Existing Users to systemd-homed managed Users](CONVERTING_TO_HOMED). [Converting Existing Users to systemd-homed managed Users](CONVERTING_TO_HOMED).
## Future Additions ## Future Additions
JSON user/group records are extensible, hence we can easily add any additional JSON user/group records are extensible, hence we can easily add any additional fields desktop environments require.
fields desktop environments require. For example, pattern-based authentication For example, pattern-based authentication is likely very useful on touch-based devices,
is likely very useful on touch-based devices, and the user records should hence and the user records should hence learn them natively.
learn them natively. Fields for other authentication mechanisms, such as Fields for other authentication mechanisms, such as fingerprint authentication should be provided as well, eventually.
fingerprint authentication should be provided as well, eventually.
It is planned to extend the `userdb` Varlink API to support look-ups by partial It is planned to extend the `userdb` Varlink API to support look-ups by partial
user name and real name (GECOS) data, so that log-in screens can optionally user name and real name (GECOS) data, so that log-in screens can optionally
@ -163,7 +155,7 @@ implement simple complete-as-you-type login screens.
It is planned to extend the `systemd-homed` D-Bus API to instantly inform clients It is planned to extend the `systemd-homed` D-Bus API to instantly inform clients
about hardware associated with a specific user being plugged in, to which login about hardware associated with a specific user being plugged in, to which login
screens can listen in order to initiate authentication. Specifically, any screens can listen in order to initiate authentication.
YubiKey-like security token plugged in that is associated with a local user Specifically, any YubiKey-like security token plugged in that is associated with a local user
record should initiate authentication for that user, making typing in of the record should initiate authentication for that user, making typing in of the
username unnecessary. username unnecessary.