Lines Matching refs:of
11 glibc NSS) `struct passwd`. Various components of systemd are able to provide
12 and consume records in a more extensible format of a dictionary of key/value
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
37 records, making them discoverable to the rest of the system.
42 for querying and enumerating records of this type, optionally acquiring them
80 also be dropped in number of drop-in directories as files. See
92 integer range of -2^63 … 2^64-1 without loss of precision (i.e. INT64_MIN …
99 structure, consisting of seven distinct "sections". Specifically:
101 1. Various fields are placed at the top-level of user record (the `regular`
105 2. A number of fields are located in the `privileged` section (a sub-object of
114 3. A number of fields are located in objects inside the `perMachine` section
115 (an array field of the user record). Primarily these are resource
118 system that has more than 1G of memory. Each object inside the `perMachine`
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
132 part of the user record only in the local context, and is generally not
141 5. Various fields are located in the `status` section (a sub-sub-object of the
146 resource usage (for example: currently used disk space of the user), that
148 record and for many purposes should be considered to be part of the user
151 6. The `signature` section contains one or more cryptographic signatures of a
152 reduced version of the user record. This is used to ensure that only user
154 the signature against the set of locally accepted signature public keys. The
159 cryptographic validation of user records is required (as it is by
171 Here's a tabular overview of the sections and their properties:
184 manage only a subset of these sections and never include the others in
185 them. For example, a service that has no concept of signed records (for example
191 authenticating users (or that doesn't have a concept of authentication at all)
192 does not need to be concerned with the `secret` section of user records, as
200 version of the record on the host, with the same four sections and augmented
215 optional. Corresponds with the `pw_name` field of of `struct passwd` and the
216 `sp_namp` field of `struct spwd` (i.e. the shadow user record stored in
229 optional, when unset the user should not be considered part of any realm. A
230 user record with a realm set is never compatible (for the purpose of updates,
233 `realName` → The real name of the user, a string. This should contain the
234 user's real ("human") name, and corresponds loosely to the GECOS field of
242 `emailAddress` → The email address of the user, formatted as
247 `iconName` → The name of an icon picked by the user, for example for the
248 purpose of an avatar. This must be a string, and should follow the semantics
252 `location` → A free-form location string describing the location of the user,
257 `disposition` → A string, one of `intrinsic`, `system`, `dynamic`, `regular`,
258 `container`, `reserved`. If specified clarifies the disposition of the user,
266 be used for any users outside of these use-cases. Note that this property is
268 disposition of a user automatically from a record even in absence of this
273 since the epoch 1970, indicating when the user record (specifically, any of the
275 used when comparing two records of the same user to identify the newer one, and
276 is used for example for automatic updating of user records, where appropriate.
279 indicating the point in time the password (or any authentication token) of the
280 user was last changed. This corresponds to the `sp_lstchg` field of `struct
284 `shell` → A string, referring to the shell binary to use for terminal logins of
285 this user. This corresponds with the `pw_shell` field of `struct passwd`, and
296 for all login sessions of the user.
298 `environment` → An array of strings, each containing an environment variable
303 for all login sessions of the user.
337 i.e. logins are permitted. This field corresponds to the `sp_expire` field of
343 the purpose of logging in.
346 shall not be permitted anymore. This corresponds to the `sp_expire` field of
350 `storage` → A string, one of `classic`, `luks`, `directory`, `subvolume`,
366 of the file system and LUKS volume, while for the others this likely translates
370 specifies a fraction of the available disk space on the selected storage medium
381 `tasksMax` → Takes an unsigned 64bit integer indicating the maximum number of
391 memory limits for all processes of the user (plus all processes forked off them
403 the `nodev`, `nosuid`, `noexec` mount flags of the user's home
418 mount as home directory of the user on login. Should be in format
420 the top-level directory of the CIFS share is used.
436 to during log-in. It corresponds to the `pw_dir` field of `struct passwd`.
439 use for the user. This corresponds to the `pw_uid` field of `struct passwd`.
442 ID (GID) to use for the user. This corresponds to the `pw_gid` field of
445 `memberOf` → An array of strings, each indicating a UNIX group this user shall
446 be a member of. The listed strings must be valid group names, but it is not
450 `fileSystemType` → A string, one of `ext4`, `xfs`, `btrfs` (possibly others) to
503 `autoResizeMode` → A string, one of `off`, `grow`, `shrink-and-grow`. Unless
512 or `true` the default weight of 100 is implied. If set to 0 or `false`
517 example, if `systemd-homed` manages a user a string of `io.systemd.Home` is
548 `killProcesses` → A boolean. If true all processes of the user are
554 encoding how much time has to pass at least/at most between password changes of
555 the user. This corresponds with the `sp_min` and `sp_max` fields of `struct
556 spwd` (i.e. the `/etc/shadow` entries of the user), but offers finer
561 `sp_warn` field of `struct spwd`.
565 deactivated. This corresponds with the `sp_inact` field of `struct spwd`.
568 on next login. This corresponds with the `sp_lstchg` field of `struct spwd`
571 `pkcs11TokenUri` → An array of strings, each with an RFC 7512 compliant PKCS#11
572 URI referring to security token (or smart card) of some form, that shall be
580 `fido2HmacCredential` → An array of strings, each with a Base64-encoded FIDO2
585 `recoveryKeyType` → An array of strings, each indicating the type of one
587 for details see the description of `recoveryKey` below. An account may have any
588 number of recovery keys defined, and the array should have one entry for each.
590 `privileged` → An object, which contains the fields of the `privileged` section
591 of the user record, see below.
593 `perMachine` → An array of objects, which contain the `perMachine` section of
597 to objects that contain the `binding` section of the user record,
602 objects that contain the `status` section of the user record, i.e. additional
603 runtime fields that expose the current status of the user record on a specific
606 `signature` → An array of objects, which contain cryptographic signatures of
607 the user record, i.e. the fields of the `signature` section of the user record,
610 `secret` → An object, which contains the fields of the `secret` section of the
615 As mentioned, the `privileged` section is encoded in a sub-object of the user
619 takes the role of the `/etc/shadow` records for each user, which has similarly
623 be a string like "What's the name of your first pet?", but is entirely for the
626 `hashedPassword` → An array of strings, each containing a hashed UNIX password
629 corresponds with `sp_pwdp` field of `struct spwd` (and in a way the `pw_passwd`
630 field of `struct passwd`).
632 `sshAuthorizedKeys` → An array of strings, each listing an SSH public key that
636 `pkcs11EncryptedKey` → An array of objects. Each element of the array should be
637 an object consisting of three string fields: `uri` shall contain a PKCS#11
643 function of the PKCS#11 module referenced by the specified URI, using the
653 `fido2HmacSalt` → An array of objects, implementing authentication support with
654 FIDO2 devices that implement the `hmac-secret` extension. Each element of the
655 array should be an object consisting of three string fields: `credential`,
662 used as string password for the further layers of the stack. The
663 `hashedPassword` field of the `fido2HmacSalt` field shall be a UNIX password
665 and `clientPin` booleans map to the FIDO2 concepts of the same name and encode
672 `recoveryKey`→ An array of objects, each defining a recovery key. The object
673 has two mandatory fields: `type` indicates the type of recovery key. The only
675 contains a UNIX password hash of the normalized recovery key. Recovery keys are
678 supported recovery key format is `modhex64`, which consists of 64
680 characters (i.e. 256bit of information), in groups of 8 chars separated by
698 The `perMachine` field in the top-level object is an array of objects. When
705 entirely undoes the setting in the top-level object (i.e. no merging of
708 here too no merging of individual fields is done, the later field always wins
713 `matchMachineId` → An array of strings that are formatted 128bit IDs in
714 hex. If any of the specified IDs match the system's local machine ID
717 `matchHostname` → An array of strings that are valid hostnames. If any of
763 fields of the bindings. These fields generally match fields that may also be
787 metrics of the user and similar metadata that shall not be persisted but are
791 sub-object of the top-level user record object is keyed by the machine ID,
795 `diskUsage` → An unsigned 64bit integer. The currently used disk space of the
798 size of the loopback file or block device size. For the
802 `diskFree` → An unsigned 64bit integer, denoting the number of "free" bytes in
809 different things (see above). In contrast to the top-level field of the same
820 `state` → A string indicating the current state of the home directory. The
821 precise set of values exposed here are up to the service managing the home
849 authentication attempt where a security token of some form was presented and it
854 authentication attempt where a security token of some form was presented and it
858 of the last successful authentication attempt in µs since the UNIX epoch (1970).
860 `lastBadAuthenticationUSec` → Similar, but the timestamp of the last
872 `removable` → A boolean value. If true the manager of this user record
889 As mentioned, the `signature` section of the user record may contain one or
890 more cryptographic signatures of the user record. Like all others, this section
891 is optional, and only used when cryptographic validation of user records shall
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
909 of the user records, all other sections (include `signature` itself), are
916 which ones shall not. A minimal level of trust must be established between
926 (which may be done by the various fields of the user record) is security
928 usage and not allow them to use more. The requirement of being able to trust
937 exist outside of the local trusted system, hence transfer and trust in the
938 source are not an issue. The major benefit of operating with signed user
941 of home directory transfer, including on USB sticks and such.
945 As mentioned, the `secret` section of the user record should never be persisted
950 The `secret` field of the top-level user record contains the following fields:
952 `password` → an array of strings, each containing a plain text password.
954 `tokenPin` → an array of strings, each containing a plain text PIN, suitable
965 use the FIDO2 "user presence" flag. This is similar to the concept of
972 concept of `pkcs11ProtectedAuthenticationPathPermitted`, but exposes the FIDO2
1015 with a short identifier of your project to avoid ambiguities and
1103 version of the user record in the home directory itself in the `~/.identity`
1105 local management of the user, but are not intended to be portable between