Lines Matching refs:fields

45 JSON user records may contain various fields that are not available in `struct
101 1. Various fields are placed at the top-level of user record (the `regular`
102    section). These are generally fields that shall apply unconditionally to the
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
116    management-related fields, as those tend to make sense on a specific system
120    which systems to apply the listed settings to. Note that many fields
125 4. Various fields are located in the `binding` section (a sub-sub-object of the
138    `binding` fields individually. Typically, the binding section is persisted
141 5. Various fields are located in the `status` section (a sub-sub-object of the
193 the fields included therein are only useful when executing authentication
210 As mentioned, the `regular` section's fields are placed at the top level
211 object. The following fields are currently defined:
226 same user name that have different realm fields are considered referring to
269 field, based on other fields, for example the numeric UID. By setting this
555 the user. This corresponds with the `sp_min` and `sp_max` fields of `struct
590 `privileged` → An object, which contains the fields of the `privileged` section
594 the user record, and thus fields to apply on specific systems only, see below.
598 i.e. additional fields that bind the user record to a specific machine, see
603 runtime fields that expose the current status of the user record on a specific
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
620 restrictive access semantics. The following fields are currently defined:
637 an object consisting of three string fields: `uri` shall contain a PKCS#11
655 array should be an object consisting of three string fields: `credential`,
656 `salt`, `hashedPassword`, and three boolean fields: `up`, `uv` and
657 `clientPin`. The first two string fields shall contain Base64-encoded binary
673 has two mandatory fields: `type` indicates the type of recovery key. The only
699 processing the user record first the various fields on the top-level object
708 here too no merging of individual fields is done, the later field always wins
711 The following fields are defined in this section:
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
723 These two are the only two fields specific to this section. All other fields
746 As mentioned, the `binding` section contains additional fields about the user
747 record, that bind it to the local system. These fields are generally used by a
748 local user manager (such as `systemd-homed.service`) to add in fields that make
754 All fields in the `binding` section only make sense in a local context and are
763 fields of the bindings. These fields generally match fields that may also be
775 The following fields are defined in the `binding` section. They all have an
785 As mentioned, the `status` section contains additional fields about the user
792 which points to the object with the fields defined here. The following fields
898 objects. Each object encapsulates one signature and has two fields: `data` and
926 (which may be done by the various fields of the user record) is security
950 The `secret` field of the top-level user record contains the following fields:
1014 * Care should be taken to avoid namespace clashes. Please prefix your fields
1019   additional fields, please consider submitting them upstream for inclusion in