system/systemd
system/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd synced 2024-07-22 02:34:54 +00:00
Code Issues Actions 5 Packages Projects Releases Wiki Activity

man,doc: document some aspects of user record management/homed a bit better

Browse source 
Fixes: #29759
This commit is contained in:
Lennart Poettering 2023-11-08 11:11:22 +01:00
parent 3cb938bd12
commit 7480859a11
2 changed files with 34 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

40
docs/USER_RECORD.md
View file

@ -704,28 +704,40 @@ for other purposes too.
The `perMachine` field in the top-level object is an array of objects. When
processing the user record first the various fields on the top-level object
should be used. Then this array should be iterated in order, and the various
settings be applied that match either the indicated machine ID or host
name. There may be multiple array entries that match a specific system, in
which case all the object's setting should be applied. If the same option is
set in the top-level object as in a per-machine object the latter wins and
entirely undoes the setting in the top-level object (i.e. no merging of
properties that are arrays themselves is done). If the same option is set in
multiple per-machine objects the one specified later in the array wins (and
here too no merging of individual fields is done, the later field always wins
in full).
should be parsed. Then, the `perMachine` array should be iterated in order, and
the various settings within each contained object should be applied that match
either the indicated machine ID or host name, overriding any corresponding
settings previously parsed from the top-level object. There may be multiple
array entries that match a specific system, in which case all settings should
be applied. If the same option is set in the top-level object as in a
per-machine object then the per-machine setting wins and entirely undoes the
setting in the top-level object (i.e. no merging of properties that are arrays
is done). If the same option is set in multiple per-machine objects the one
specified later in the array wins (and here too no merging of individual fields
is done, the later field always wins in full). To summarize, the order of
application is (last one wins):
1. Settings in the top-level object
2. Settings in the first matching `perMachine` array entry
3. Settings in the second matching `perMachine` array entry
4. …
5. Settings in the last matching `perMachine` array entry
The following fields are defined in this section:
`matchMachineId` → An array of strings that are formatted 128-bit IDs in
hex. If any of the specified IDs match the system's local machine ID
(i.e. matches `/etc/machine-id`) the fields in this object are honored.
(i.e. matches `/etc/machine-id`) the fields in this object are honored. (As a
special case, if only a single machine ID is listed this field may be a single
string rather than an array of strings.)
`matchHostname` → An array of strings that are valid hostnames. If any of
the specified hostnames match the system's local hostname, the fields in this
`matchHostname` → An array of strings that are valid hostnames. If any of the
specified hostnames match the system's local hostname, the fields in this
object are honored. If both `matchHostname` and `matchMachineId` are used
within the same array entry, the object is honored when either match succeeds,
i.e. the two match types are combined in OR, not in AND.
i.e. the two match types are combined in OR, not in AND. (As a special case, if
only a single machine ID is listed this field may be a single string rather
than an array of strings.)
These two are the only two fields specific to this section. All other fields
that may be used in this section are identical to the equally named ones in the

11
man/org.freedesktop.home1.xml
View file

@ -305,9 +305,14 @@ node /org/freedesktop/home1 {
user record with the new passwords/authentication token data is specified as empty the existing user
record's settings are propagated down to the home directory storage. This is typically used after a
user record is updated using <function>UpdateHome()</function> in order to propagate the
secrets/authentication tokens down to the storage. This method is equivalent to
<function>ChangePassword()</function> on the <classname>org.freedesktop.home1.Home</classname>
interface.</para>
secrets/authentication tokens down to the storage. Background: depending on the backend the user's
authentication credentials are stored at multiple places: the user record kept on the host, the user
record kept in the home directory and the encrypted LUKS volume slot. If the home directory is used on
a different machined temporarily, and the password is changed there, and then is moved back to the
original host, the passwords of the three might get out of sync. By issuing
<function>ChangePasswordHome()</function> the three locations are updated to match the newest
information. This method is equivalent to <function>ChangePassword()</function> on the
<classname>org.freedesktop.home1.Home</classname> interface.</para>
<para><function>LockHome()</function> temporarily suspends access to a home directory, flushing out any
cryptographic keys from memory. This is only supported on some back-ends, and usually done during system