Lines Matching refs:in
12 and consume records in a more extensible format of a dictionary of key/value
17 directly in the home directory images
21 processes these JSON records for users that log in, and applies various
26 processes these JSON records of users that log in, and applies various
36 effect of `DynamicUser=` in service unit files) as these advanced JSON
45 JSON user records may contain various fields that are not available in `struct
77 JSON User Records may be transferred or written to disk in various protocols
80 also be dropped in number of drop-in directories as files. See
88 popular in the web communities, which hopefully should make it easy to link
103 user in all contexts, are portable and not security sensitive.
105 2. A number of fields are located in the `privileged` section (a sub-object of
106 the user record). Fields contained in this object are security sensitive,
109 stored in `/etc/shadow` in classic Linux user accounts, i.e. includes
111 an untrusted client, by monopolizing such sensitive records in a single
114 3. A number of fields are located in objects inside the `perMachine` section
121 accepted in the `perMachine` section can also be set at the top level (the
122 `regular` section), where they define the fallback if no matching object in
125 4. Various fields are located in the `binding` section (a sub-sub-object of the
127 machine ID of the host). Fields included in this section "bind" the object
131 record manager (such as `systemd-homed`). Data in this section is considered
132 part of the user record only in the local context, and is generally not
133 ported to other systems. Due to that it is not included in the reduced user
134 record the cryptographic signature defined in the `signature` section is
136 user's record is stored in the `~/.identity` file in the home directory, so
141 5. Various fields are located in the `status` section (a sub-sub-object of the
165 be included in a user record very briefly, for example when certain very
166 specific operations are executed. For example, in tools such as
167 `systemd-homed` this section may be included in user records, when creating
173 | Section | Included in Signature | Persistent | Security Sensitive | Contains Host-Specific Dat…
184 manage only a subset of these sections and never include the others in
187 bother with the `signature` section. A service that only defines records in a
189 `perMachine` or `binding` sections and can include its data exclusively in the
198 in the LUKS2 header) a user record containing the `regular`, `privileged`,
202 a user record managed by `systemd-homed` the service will add in some
203 additional information about the user and home directory in the `status`
206 IPC to transfer the user record along with its authentication tokens in one go.
208 ## Fields in the `regular` section
216 `sp_namp` field of `struct spwd` (i.e. the shadow user record stored in
220 `realm` → The "realm" a user is defined in. This concept allows distinguishing
221 users with the same name that originate in different organizations or
222 installations. This should take a string in DNS domain syntax, but doesn't have
224 this). The idea is that the user `lpoetter` in the `redhat.com` realm might be
225 distinct from the same user in the `poettering.hq` realm. User records for the
228 version has to match in both `userName` and `realm` field. This field is
240 as record separators in classic `/etc/passwd` files and similar formats.
249 defined in the [Icon Naming
259 i.e. the context it is defined in. For regular, "human" users this should be
264 users that are used by an OS container, and hence will show up in `ps` listings
265 and such, but are only defined in container context. Finally `reserved` should
268 disposition of a user automatically from a record even in absence of this
272 `lastChangeUSec` → An unsigned 64bit integer value, referring to a timestamp in µs
279 indicating the point in time the password (or any authentication token) of the
281 spwd`, i.e. the matching field in the user shadow database `/etc/shadow`,
287 terminal log-in this field should not be set.
290 integer. Note that usually on UNIX the umask is noted in octal, but JSON's
291 integers are generally written in decimal, hence in this context we denote it
292 umask in decimal too. The specified value should be in the valid range for
293 umasks, i.e. 0000…0777 (in octal as typical in UNIX), or 0…511 (in decimal, how
294 it actually appears in the JSON record). This `umask` is automatically set by
299 and its value to set for the user's login session, in a format compatible with
306 logging in
313 user. When logging in
316 string. The string hence should be in a format compatible with this environment
319 `niceLevel` → An integer value in the range -20…19. When logging in
328 two keys `cur` and `max` for the soft and hard resource limit. When logging in
336 not log in. If this field is missing it should be assumed to be false,
341 `notBeforeUSec` → An unsigned 64bit integer value, indicating a time in µs since
343 the purpose of logging in.
345 `notAfterUSec` → Similar, but indicates the point in time *after* which logins
352 directory. If `classic` the home directory is a plain directory as in classic
354 `~/.identity` file in it contains the user's user record, so that the directory
364 disk space in bytes to assign to the user. Depending on the selected storage
378 `accessMode` → Takes an unsigned integer in the range 0…511 indicating the UNIX
382 tasks the user may start in parallel during system runtime. This counts
392 that might have changed user identity), in bytes. Enforced by
396 `cpuWeight`/`ioWeight` → These take unsigned integers in the range 1…10000
418 mount as home directory of the user on login. Should be in format
433 directory. This is where the image indicated in `imagePath` is mounted to on
436 to during log-in. It corresponds to the `pw_dir` field of `struct passwd`.
438 `uid` → An unsigned integer in the range 0…4294967295: the numeric UNIX user ID (UID) to
441 `gid` → An unsigned integer in the range 0…4294967295: the numeric UNIX group
447 required that all groups listed exist in all contexts: any entry for which no
456 the GPT partition UUID the home directory is located in. This is primarily
460 the LUKS volume UUID the home directory is located in. This is primarily
464 referencing the file system UUID the home directory is located in. This is
468 the loopback block devices, LUKS and the file system on top shall be used in
479 the default mount options for the file system in the LUKS volume.
485 `luksVolumeKeySize` → An unsigned integer, indicating the volume key length in
494 time cost for the PBKDF operation, when the LUKS storage mechanism is used, in
498 memory cost for the PBKDF operation, when LUKS storage is used, in bytes.
505 the size configured in `diskSize` automatically at login time. If set to
510 free disk space rebalancing weight for the home area. The integer must be in
522 timer interval (in µs) within which to count authentication attempts. When the
536 auto-login. Systems are supposed to automatically log in a user marked this way
539 `stopDelayUSec` → An unsigned 64bit integer, indicating the time in µs the
545 necessary work to set up and tear down a log-in is reduced if the service
560 warn the user before their password expires, in µs. This corresponds with the
576 below). It's undefined how precise the URI is: during log-in it is tested
577 against all plugged in security tokens and if there's exactly one matching
583 found in `fido2HmacSalt`.
613 ## Fields in the `privileged` section
615 As mentioned, the `privileged` section is encoded in a sub-object of the user
616 record top-level object, in the `privileged` field. Any data included in this
622 `passwordHint` → A user-selected password hint in free-form text. This should
627 string, in the format
629 corresponds with `sp_pwdp` field of `struct spwd` (and in a way the `pw_passwd`
634 as the lines in the traditional `~/.ssh/authorized_key` file.
647 during log-in, for example the LUKS or `fscrypt` storage backend. It is
648 generally recommended that for each entry in `pkcs11EncryptedKey` there's also
649 a matching one in `pkcs11TokenUri` and vice versa, with the same URI, appearing
650 in the same order, but this should not be required by applications processing
668 entry in `fido2HmacSalt` there's also a matching one in `fido2HmacCredential`,
669 and vice versa, with the same credential ID, appearing in the same order, but
676 in most ways similar to regular passwords, except that they are generated by
680 characters (i.e. 256bit of information), in groups of 8 chars separated by
685 entry in either should map 1:1 to an entry in the other, in the same order and
691 ## Fields in the `perMachine` section
698 The `perMachine` field in the top-level object is an array of objects. When
700 should be used. Then this array should be iterated in order, and the various
702 name. There may be multiple array entries that match a specific system, in
704 set in the top-level object as in a per-machine object the latter wins and
705 entirely undoes the setting in the top-level object (i.e. no merging of
706 properties that are arrays themselves is done). If the same option is set in
707 multiple per-machine objects the one specified later in the array wins (and
709 in full).
711 The following fields are defined in this section:
713 `matchMachineId` → An array of strings that are formatted 128bit IDs in
715 (i.e. matches `/etc/machine-id`) the fields in this object are honored.
718 the specified hostnames match the system's local hostname, the fields in this
721 i.e. the two match types are combined in OR, not in AND.
724 that may be used in this section are identical to the equally named ones in the
744 ## Fields in the `binding` section
748 local user manager (such as `systemd-homed.service`) to add in fields that make
749 sense in a local context but not necessarily in a global one. For example, a
750 user record that contains no `uid` field in the regular section is likely
751 extended with one in the `binding` section to assign a local UID if no global
754 All fields in the `binding` section only make sense in a local context and are
756 is generally persisted on the system but not in the home directories themselves
764 defined in the `regular` and `perMachine` sections, however override
768 storage mechanism in the `regular` section, but the local kernel does not
770 been changed in the `regular` section through updates (e.g. a home directory
773 used already which is pinned in the `binding` section).
775 The following fields are defined in the `binding` section. They all have an
776 identical format and override their equally named counterparts in the `regular`
783 ## Fields in the `status` section
796 home directory in bytes. This value might be determined in different ways,
802 `diskFree` → An unsigned 64bit integer, denoting the number of "free" bytes in
804 reported by `diskSize` and the used already as reported in `diskFree`, but
808 allotted to the user, in bytes. Depending on the storage mechanism this can mean
810 (or the one in the `perMachine` section), this field reports the current size
815 bounds when changing the `diskSize` value, in bytes. These values are typically
816 derived from the underlying data storage, and indicate in which range the home
817 directory may be re-sized in, i.e. in which sensible range the `diskSize` value
832 in which `state` lives, see above. Note that this field also exists on the
833 top-level object (i.e. in the `regular` section), which it overrides. The
858 of the last successful authentication attempt in µs since the UNIX epoch (1970).
868 attempts in the current rate limiting interval, see above. If this counter
869 grows beyond the value configured in `rateLimitBurst` authentication attempts
874 determined the home directory is in internal built-in media. (This is used by
878 home directory remains in unclean state if the storage device is removed from
881 `accessMode` → The access mode currently in effect for the home directory
887 ## Fields in the `signature` section
897 The `signature` field in the top-level user record object is an array of
900 encoded in Base64, the `key` field contains a copy of the public key whose
901 private key was used to make the signature, in PEM format. Currently only
905 i.e. the keys in all objects should be sorted alphabetically. All redundant
917 system, user record and the user themselves before a log-in request may be
918 permitted. In particular if the home directory is provided in its own LUKS2
920 user logs in (and hence the file system mounted), since file system
922 disk images. User records and home directories in many context are expected to
931 signed by a recognized key are permitted to log in locally.
936 channels only. Or traditional UNIX users created locally in `/etc/passwd` never
937 exist outside of the local trusted system, hence transfer and trust in the
943 ## Fields in the `secret` section
946 nor transferred across machines. It is only defined in short-lived operations,
957 in case both are set.)
998 | `struct spwd` | `sp_expire` | `regular` | `locked` | (if `sp_expire` in …
1002 `pw_passwd` field in `struct passwd` is set to `"x"`, and the actual password
1003 is stored in the shadow entry `struct spwd`'s field `sp_pwdp`.
1011 * Care should be taken to place the keys in the right section, i.e. the most
1019 additional fields, please consider submitting them upstream for inclusion in
1103 version of the user record in the home directory itself in the `~/.identity`