Lines Matching refs:user

10 systemd optionally processes user records that go beyond the classic UNIX (or
16    manages `human` user home directories and embeds these JSON records
27    resource management settings to the per-user slice units it manages. This
28    allows setting global limits on resource consumption by a specific user.
41    user records. It also provides a unified [Varlink](https://varlink.org/) API
45 JSON user records may contain various fields that are not available in `struct
52 2. Additional user metadata, such as a picture, email address, location string,
68 2. Information about default IMAP, SMTP servers to use for this user
70 3. Parental control information to enforce on this user
89 user credential data from the web and from local systems more closely together.
93 UINT64_MAX). Please read, write and process user records as defined by this
98 The JSON user records generated and processed by systemd follow a general
101 1. Various fields are placed at the top-level of user record (the `regular`
103    user in all contexts, are portable and not security sensitive.
106    the user record). Fields contained in this object are security sensitive,
107    i.e. contain information that the user and the administrator should be able
109    stored in `/etc/shadow` in classic Linux user accounts, i.e. includes
110    password hashes and more. Algorithmically, when a user record is passed to
115    (an array field of the user record). Primarily these are resource
117    only, e.g. limiting a user's memory use to 1G only makes sense on a specific
126    user record; an intermediary object is inserted which is keyed by the
130    necessarily on others, and which are managed automatically by some user
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
136    user's record is stored in the `~/.identity` file in the home directory, so
142    user record, also with an intermediary object between that is keyed by the
146    resource usage (for example: currently used disk space of the user), that
147    changes dynamically but is otherwise immediately associated with the user
148    record and for many purposes should be considered to be part of the user
152    reduced version of the user record. This is used to ensure that only user
155    signature is calculated from the JSON user record with all sections removed,
159    cryptographic validation of user records is required (as it is by
162 7. The `secret` section contains secret user credentials, such as password or
163    PIN information. This data is never persisted, and never returned when user
165    be included in a user record very briefly, for example when certain very
167    `systemd-homed` this section may be included in user records, when creating
183 Note that services providing user records to the local system are free to
192 does not need to be concerned with the `secret` section of user records, as
194 operations natively against JSON user records.
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.
213 `userName` → The UNIX user name for this record. Takes a string with a valid
214 UNIX user name. This field is the only mandatory field, all others are
216 `sp_namp` field of `struct spwd` (i.e. the shadow user record stored in
218 the (relaxed) rules the various systemd components enforce on user/group names.
220 `realm` → The "realm" a user is defined in. This concept allows distinguishing
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
226 same user name that have different realm fields are considered referring to
227 different users. When updating a user record it is required that any new
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,
231 see above) with a user record without one set, even if the `userName` field matches.
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
235 classic UNIX user records. When converting a `struct passwd` to a JSON user
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
252 `location` → A free-form location string describing the location of the user,
258 `container`, `reserved`. If specified clarifies the disposition of the user,
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.
280 user was last changed. This corresponds to the `sp_lstchg` field of `struct
281 spwd`, i.e. the matching field in the user shadow database `/etc/shadow`,
285 this user. This corresponds with the `pw_shell` field of `struct passwd`, and
289 `umask` → The `umask` to set for the user's login sessions. Takes an
296 for all login sessions of the user.
299 and its value to set for the user's login session, in a format compatible with
303 for all login sessions of the user.
305 `timeZone` → A string indicating a preferred timezone to use for the user. When
313 user. When logging in
322 which is then inherited by all the user's processes, see
331 values, which is then inherited by all the user's processes, see
335 `locked` → A boolean value. If true, the user account is locked, the user may
338 `struct spwd` (i.e. the `/etc/shadow` data for a user) being set to zero or
351 `fscrypt`, `cifs`. Indicates the storage mechanism for the user's home
354 `~/.identity` file in it contains the user's user record, so that the directory
356 contains a `~/.identity` user record; `fscrypt` is an `fscrypt`-encrypted
357 directory, also containing the `~/.identity` user record; `luks` is a per-user
364 disk space in bytes to assign to the user. Depending on the selected storage
371 to assign to the user. This unsigned integer value is normalized to 2^32 =
382 tasks the user may start in parallel during system runtime. This counts
383 all tasks (i.e. threads, where each process is at least one thread) the user starts or that are
384 forked from these processes even if the user identity is changed (for example
387 enforces this by setting the `TasksMax` slice property for the user's slice
388 `user-$UID.slice`.
391 memory limits for all processes of the user (plus all processes forked off them
392 that might have changed user identity), in bytes. Enforced by
398 user's processes as a whole. Also enforced by
403 the `nodev`, `nosuid`, `noexec` mount flags of the user's home
410 mechanism for the user's home directory, see above.
412 `cifsUserName` → A string indicating the Windows File Sharing user name (CIFS)
413 to associate this user record with. This is generally useful, but particularly
414 useful when `cifs` is used as storage mechanism for the user's home directory,
418 mount as home directory of the user on login. Should be in format
435 directory is active, and is what the user's `$HOME` environment variable is set
438 `uid` → An unsigned integer in the range 0…4294967295: the numeric UNIX user ID (UID) to
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
451 use as file system for the user's home directory. This is primarily relevant
515 `service` → A string declaring the service that defines or manages this user
517 example, if `systemd-homed` manages a user a string of `io.systemd.Home` is
521 authentication rate limiting enforced on the user account. This specifies a
531 password policy when creating the home directory for the user or changing the
532 user's password. By default the policy is enforced, but if this field is false
535 `autoLogin` → A boolean. If true the user record is marked as suitable for
536 auto-login. Systems are supposed to automatically log in a user marked this way
537 during boot, if there's exactly one user on it defined this way.
540 per-user service manager is kept around after the user fully logged out.  This
543 set to zero the per-user service manager is immediately terminated when the
544 user logs out, and longer values optimize high-frequency log-ins as the
548 `killProcesses` → A boolean. If true all processes of the user are
549 automatically killed when the user logs out. This is enforced by
551 false any processes left around when the user logs out are left running.
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
560 warn the user before their password expires, in µs. This corresponds with the
567 `passwordChangeNow` → A boolean. If true the user has to change their password
573 associated with the user and may be used for authentication. The URI is used to
575 decrypt an encrypted secret key that is used to unlock the user's account (see
591 of the user record, see below.
594 the user record, and thus fields to apply on specific systems only, see below.
597 to objects that contain the `binding` section of the user record,
598 i.e. additional fields that bind the user record to a specific machine, see
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
607 the user record, i.e. the fields of the `signature` section of the user record,
611 user record, see below.
615 As mentioned, the `privileged` section is encoded in a sub-object of the user
617 object shall only be visible to the administrator and the user themselves, and
618 be suppressed implicitly when other users get access to a user record. It thus
619 takes the role of the `/etc/shadow` records for each user, which has similarly
622 `passwordHint` → A user-selected password hint in free-form text. This should
624 user to choose.
651 user records.
670 this should not be required by applications processing user records.
677 the computer, not chosen by the user, and are longer. Currently, the only
699 processing the user record first the various fields on the top-level object
746 As mentioned, the `binding` section contains additional fields about the user
748 local user manager (such as `systemd-homed.service`) to add in fields that make
750 user record that contains no `uid` field in the regular section is likely
755 suppressed when the user record is ported between systems. The `binding` section
761 The `binding` sub-object on the top-level user record object is keyed by the
771 was created with `luks` as storage mechanism but later the user record was
785 As mentioned, the `status` section contains additional fields about the user
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,
808 allotted to the user, in bytes. Depending on the storage mechanism this can mean
811 allotted to the user, not the intended one. The values may differ when user
829 `service` → A string identifying the service that manages this user record. For
830 example `systemd-homed.service` sets this to `io.systemd.Home` to all user
834 `regular` field should be used if conceptually the user record can only be
839 `signedLocally` → A boolean. If true indicates that the user record is signed
841 the user record may be modified locally as it can be re-signed with the private
842 key. If false indicates that the user record is signed by a public key
844 locally. This means the user record cannot be modified locally as it couldn't
872 `removable` → A boolean value. If true the manager of this user record
879 the system by the user).
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
892 be used. Specifically, all user records managed by `systemd-homed.service` will
893 carry such signatures and the service refuses managing user records that come
897 The `signature` field in the top-level user record object is an array of
904 Before signing the user record should be brought into "normalized" form,
909 of the user records, all other sections (include `signature` itself), are
912 Rationale for signing and threat model: while a multi-user operating system
913 like Linux strives for being sufficiently secure even after a user acquired a
917 system, user record and the user themselves before a log-in request may be
920 user logs in (and hence the file system mounted), since file system
925 the user record is not manipulated between uses. Finally, resource management
926 (which may be done by the various fields of the user record) is security
927 sensitive, since it should forcefully lock the user into the assigned resource
929 the user record data combined with the potential transfer over untrusted
930 channels suggest a cryptographic signature mechanism where only user records
935 generally insist on user record transfer from trusted servers via encrypted TLS
938 source are not an issue. The major benefit of operating with signed user
945 As mentioned, the `secret` section of the user record should never be persisted
947 for example when a user record is first created or registered, as the secret
950 The `secret` field of the top-level user record contains the following fields:
962 user. If false or unset, authentication this way shall not be attempted.
965 use the FIDO2 "user presence" flag. This is similar to the concept of
971 receiver to use the FIDO2 "user verification" flag. This is similar to the
978 When mapping classic UNIX user records (i.e. `struct passwd` and `struct spwd`)
979 to JSON user records the following mappings should be applied:
1025 The shortest valid user record looks like this:
1033 A reasonable user record for a system user might look like this:
1045 A fully featured user record associated with a home directory managed by
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