tree-wide: "<n>bit" → "<n>-bit"
In some places, "<n> bits" is used when more appropriate.
This commit is contained in:
Zbigniew Jędrzejewski-Szmek
committed by
Luca Boccassi
Luca Boccassi
parent
221332ee13
commit
da89046643
@@ -67,7 +67,7 @@ variables. All EFI variables use the vendor UUID
|
||||
identifier that was booted. It is set by the boot loader and read by
|
||||
the OS in order to identify which entry has been used for the current boot.
|
||||
|
||||
* The EFI variable `LoaderFeatures` contains a 64bit unsigned integer with a
|
||||
* The EFI variable `LoaderFeatures` contains a 64-bit unsigned integer with a
|
||||
number of flags bits that are set by the boot loader and passed to the OS and
|
||||
indicate the features the boot loader supports. Specifically, the following
|
||||
bits are defined:
|
||||
|
||||
@@ -27,7 +27,7 @@ boot. For that it's essential to:
|
||||
1. Remove the
|
||||
[`/etc/machine-id`](https://www.freedesktop.org/software/systemd/man/machine-id.html)
|
||||
file or write the string `uninitialized\n` into it. This file is supposed to
|
||||
carry a 128bit identifier unique to the system. Only when it is reset it
|
||||
carry a 128-bit identifier unique to the system. Only when it is reset it
|
||||
will be auto-generated on first boot and thus be truly unique. If this file
|
||||
is not reset, and carries a valid ID every instance of the system will come
|
||||
up with the same ID and that will likely lead to problems sooner or later,
|
||||
|
||||
@@ -118,7 +118,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
||||
compatibility. Since we typically want to allow adding new enum values to an
|
||||
existing enum type with later API versions, please use the
|
||||
`_SD_ENUM_FORCE_S64()` macro in the enum definition, which forces the size of
|
||||
the enum to be signed 64bit wide.
|
||||
the enum to be signed 64-bit wide.
|
||||
|
||||
- Empty lines to separate code blocks are a good thing, please add them
|
||||
abundantly. However, please stick to one at a time, i.e. multiple empty lines
|
||||
|
||||
@@ -74,7 +74,7 @@ not contain any control character, nor use `\uXXX` escaping.
|
||||
|
||||
When it comes to JSON numbers, this specification assumes that JSON parsers
|
||||
processing this information are capable of reproducing the full signed 53bit
|
||||
integer range (i.e. -2⁵³+1…+2⁵³-1) as well as the full 64bit IEEE floating
|
||||
integer range (i.e. -2⁵³+1…+2⁵³-1) as well as the full 64-bit IEEE floating
|
||||
point number range losslessly (with the exception of NaN/-inf/+inf, since JSON
|
||||
cannot encode that), as per recommendations of
|
||||
[RFC8259](https://datatracker.ietf.org/doc/html/rfc8259#page-8). Fields in
|
||||
|
||||
@@ -33,7 +33,7 @@ same field of user records. A string.
|
||||
`service` → A string, an identifier for the service managing this group record
|
||||
(this field is typically in reverse domain name syntax.)
|
||||
|
||||
`lastChangeUSec` → An unsigned 64bit integer, a timestamp (in µs since the UNIX
|
||||
`lastChangeUSec` → An unsigned 64-bit integer, a timestamp (in µs since the UNIX
|
||||
epoch 1970) of the last time the group record has been modified. (Covers only
|
||||
the `regular`, `perMachine` and `privileged` sections).
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ When exporting journal data for other uses or transferring it via the network/lo
|
||||
|
||||
* Two journal entries that follow each other are separated by a double newline.
|
||||
* Journal fields consisting only of valid non-control UTF-8 codepoints are serialized as they are (i.e. the field name, followed by '=', followed by field data), followed by a newline as separator to the next field. Note that fields containing newlines cannot be formatted like this. Non-control UTF-8 codepoints are the codepoints with value at or above 32 (' '), or equal to 9 (TAB).
|
||||
* Other journal fields are serialized in a special binary safe way: field name, followed by newline, followed by a binary 64bit little endian size value, followed by the binary field data, followed by a newline as separator to the next field.
|
||||
* Other journal fields are serialized in a special binary safe way: field name, followed by newline, followed by a binary 64-bit little endian size value, followed by the binary field data, followed by a newline as separator to the next field.
|
||||
* Entry metadata that is not actually a field is serialized like it was a field, but beginning with two underscores. More specifically, `__CURSOR=`, `__REALTIME_TIMESTAMP=`, `__MONOTONIC_TIMESTAMP=`, `__SEQNUM=`, `__SEQNUM_ID` are introduced this way. Note that these meta-fields are only generated when actual journal files are serialized. They are omitted for entries that do not originate from a journal file (for example because they are transferred for the first time to be stored in one). Or in other words: if you are generating this format you shouldn't care about these special double-underscore fields. But you might find them usable when you deserialize the format generated by us. Additional fields prefixed with two underscores might be added later on, your parser should skip over the fields it does not know.
|
||||
* The order in which fields appear in an entry is undefined and might be different for each entry that is serialized.
|
||||
And that's already it.
|
||||
|
||||
@@ -71,15 +71,15 @@ thread](https://lists.freedesktop.org/archives/systemd-devel/2012-October/007054
|
||||
|
||||
## Basics
|
||||
|
||||
* All offsets, sizes, time values, hashes (and most other numeric values) are 32bit/64bit unsigned integers in LE format.
|
||||
* All offsets, sizes, time values, hashes (and most other numeric values) are 32-bit/64-bit unsigned integers in LE format.
|
||||
* Offsets are always relative to the beginning of the file.
|
||||
* The 64bit hash function siphash24 is used for newer journal files. For older files [Jenkins lookup3](https://en.wikipedia.org/wiki/Jenkins_hash_function) is used, more specifically `jenkins_hashlittle2()` with the first 32bit integer it returns as higher 32bit part of the 64bit value, and the second one uses as lower 32bit part.
|
||||
* All structures are aligned to 64bit boundaries and padded to multiples of 64bit
|
||||
* The 64-bit hash function siphash24 is used for newer journal files. For older files [Jenkins lookup3](https://en.wikipedia.org/wiki/Jenkins_hash_function) is used, more specifically `jenkins_hashlittle2()` with the first 32-bit integer it returns as higher 32-bit part of the 64-bit value, and the second one uses as lower 32-bit part.
|
||||
* All structures are aligned to 64-bit boundaries and padded to multiples of 64-bit
|
||||
* The format is designed to be read and written via memory mapping using multiple mapped windows.
|
||||
* All time values are stored in usec since the respective epoch.
|
||||
* Wall clock time values are relative to the Unix time epoch, i.e. January 1st, 1970. (`CLOCK_REALTIME`)
|
||||
* Monotonic time values are always stored jointly with the kernel boot ID value (i.e. `/proc/sys/kernel/random/boot_id`) they belong to. They tend to be relative to the start of the boot, but aren't for containers. (`CLOCK_MONOTONIC`)
|
||||
* Randomized, unique 128bit IDs are used in various locations. These are generally UUID v4 compatible, but this is not a requirement.
|
||||
* Randomized, unique 128-bit IDs are used in various locations. These are generally UUID v4 compatible, but this is not a requirement.
|
||||
|
||||
## General Rules
|
||||
|
||||
@@ -547,7 +547,7 @@ plus their respective hashes (which are calculated the same way as in the DATA
|
||||
objects, i.e. keyed by the file ID).
|
||||
|
||||
If the `HEADER_INCOMPATIBLE_COMPACT` flag is set, DATA object offsets are stored
|
||||
as 32-bit integers instead of 64bit and the unused hash field per data object is
|
||||
as 32-bit integers instead of 64-bit and the unused hash field per data object is
|
||||
not stored anymore.
|
||||
|
||||
In the file ENTRY objects are written ordered monotonically by sequence
|
||||
@@ -615,7 +615,7 @@ arrays are strictly sorted by offsets on disk, and hence by their timestamps
|
||||
and sequence numbers (with some restrictions, see above).
|
||||
|
||||
If the `HEADER_INCOMPATIBLE_COMPACT` flag is set, offsets are stored as 32-bit
|
||||
integers instead of 64bit.
|
||||
integers instead of 64-bit.
|
||||
|
||||
Entry Arrays are chained up. If one entry array is full another one is
|
||||
allocated and the **next_entry_array_offset** field of the old one pointed to
|
||||
|
||||
@@ -70,7 +70,7 @@ key `FOO` with a value `BAR` is serialized `F`, `O`, `O`, `=`, `B`, `A`, `R`,
|
||||
|
||||
* The second method should be used if the value of a field contains a `\n`
|
||||
byte. In this case, the key name is serialized as is, followed by a `\n`
|
||||
character, followed by a (non-aligned) little-endian unsigned 64bit integer
|
||||
character, followed by a (non-aligned) little-endian unsigned 64-bit integer
|
||||
encoding the size of the value, followed by the literal value data, followed by
|
||||
`\n`. Example: a key `FOO` with a value `BAR` may be serialized using this
|
||||
second method as: `F`, `O`, `O`, `\n`, `\003`, `\000`, `\000`, `\000`, `\000`,
|
||||
|
||||
+21
-21
@@ -18,14 +18,14 @@ validity for GIDs too.
|
||||
|
||||
## Special Linux UIDs
|
||||
|
||||
In theory, the range of the C type `uid_t` is 32bit wide on Linux,
|
||||
In theory, the range of the C type `uid_t` is 32-bit wide on Linux,
|
||||
i.e. 0…4294967295. However, four UIDs are special on Linux:
|
||||
|
||||
1. 0 → The `root` super-user
|
||||
|
||||
2. 65534 → The `nobody` UID, also called the "overflow" UID or similar. It's
|
||||
where various subsystems map unmappable users to, for example file systems
|
||||
only supporting 16bit UIDs, NFS or user namespacing. (The latter can be
|
||||
only supporting 16-bit UIDs, NFS or user namespacing. (The latter can be
|
||||
changed with a sysctl during runtime, but that's not supported on
|
||||
`systemd`. If you do change it you void your warranty.) Because Fedora is a
|
||||
bit confused the `nobody` user is called `nfsnobody` there (and they have a
|
||||
@@ -33,13 +33,13 @@ i.e. 0…4294967295. However, four UIDs are special on Linux:
|
||||
though. (Also, some distributions call the `nobody` group `nogroup`. I wish
|
||||
they didn't.)
|
||||
|
||||
3. 4294967295, aka "32bit `(uid_t) -1`" → This UID is not a valid user ID, as
|
||||
3. 4294967295, aka "32-bit `(uid_t) -1`" → This UID is not a valid user ID, as
|
||||
`setresuid()`, `chown()` and friends treat -1 as a special request to not
|
||||
change the UID of the process/file. This UID is hence not available for
|
||||
assignment to users in the user database.
|
||||
|
||||
4. 65535, aka "16bit `(uid_t) -1`" → Before Linux kernel 2.4 `uid_t` used to be
|
||||
16bit, and programs compiled for that would hence assume that `(uid_t) -1`
|
||||
4. 65535, aka "16-bit `(uid_t) -1`" → Before Linux kernel 2.4 `uid_t` used to be
|
||||
16-bit, and programs compiled for that would hence assume that `(uid_t) -1`
|
||||
is 65535. This UID is hence not usable either.
|
||||
|
||||
The `nss-systemd` glibc NSS module will synthesize user database records for
|
||||
@@ -108,7 +108,7 @@ but downstreams are strongly advised against doing that.)
|
||||
2. 61184…65519 → UIDs for dynamic users are allocated from this range (see the
|
||||
`DynamicUser=` documentation in
|
||||
[`systemd.exec(5)`](https://www.freedesktop.org/software/systemd/man/systemd.exec.html)). This
|
||||
range has been chosen so that it is below the 16bit boundary (i.e. below
|
||||
range has been chosen so that it is below the 16-bit boundary (i.e. below
|
||||
65535), in order to provide compatibility with container environments that
|
||||
assign a 64K range of UIDs to containers using user namespacing. This range
|
||||
is above the 60000 boundary, so that its allocations are unlikely to be
|
||||
@@ -122,15 +122,15 @@ but downstreams are strongly advised against doing that.)
|
||||
|
||||
3. 524288…1879048191 → UID range for `systemd-nspawn`'s automatic allocation of
|
||||
per-container UID ranges. When the `--private-users=pick` switch is used (or
|
||||
`-U`) then it will automatically find a so far unused 16bit subrange of this
|
||||
`-U`) then it will automatically find a so far unused 16-bit subrange of this
|
||||
range and assign it to the container. The range is picked so that the upper
|
||||
16bit of the 32bit UIDs are constant for all users of the container, while
|
||||
the lower 16bit directly encode the 65536 UIDs assigned to the
|
||||
container. This mode of allocation means that the upper 16bit of any UID
|
||||
assigned to a container are kind of a "container ID", while the lower 16bit
|
||||
16-bit of the 32-bit UIDs are constant for all users of the container, while
|
||||
the lower 16-bit directly encode the 65536 UIDs assigned to the
|
||||
container. This mode of allocation means that the upper 16-bit of any UID
|
||||
assigned to a container are kind of a "container ID", while the lower 16-bit
|
||||
directly expose the container's own UID numbers. If you wonder why precisely
|
||||
these numbers, consider them in hexadecimal: 0x00080000…0x6FFFFFFF. This
|
||||
range is above the 16bit boundary. Moreover it's below the 31bit boundary,
|
||||
range is above the 16-bit boundary. Moreover it's below the 31-bit boundary,
|
||||
as some broken code (specifically: the kernel's `devpts` file system)
|
||||
erroneously considers UIDs signed integers, and hence can't deal with values
|
||||
above 2^31. The `systemd-machined.service` service will synthesize user
|
||||
@@ -185,7 +185,7 @@ assign to your containers, here are a few recommendations:
|
||||
|
||||
1. Definitely, don't assign less than 65536 UIDs/GIDs. After all the `nobody`
|
||||
user has magic properties, and hence should be available in your container, and
|
||||
given that it's assigned the UID 65534, you should really cover the full 16bit
|
||||
given that it's assigned the UID 65534, you should really cover the full 16-bit
|
||||
range in your container. Note that systemd will — as mentioned — synthesize
|
||||
user records for the `nobody` user, and assumes its availability in various
|
||||
other parts of its codebase, too, hence assigning fewer users means you lose
|
||||
@@ -195,15 +195,15 @@ other packages make similar restrictions.
|
||||
2. While it's fine to assign more than 65536 UIDs/GIDs to a container, there's
|
||||
most likely not much value in doing so, as Linux distributions won't use the
|
||||
higher ranges by default (as mentioned neither `adduser` nor `systemd`'s
|
||||
dynamic user concept allocate from above the 16bit range). Unless you actively
|
||||
dynamic user concept allocate from above the 16-bit range). Unless you actively
|
||||
care for nested containers, it's hence probably a good idea to allocate exactly
|
||||
65536 UIDs per container, and neither less nor more. A pretty side-effect is
|
||||
that by doing so, you expose the same number of UIDs per container as Linux 2.2
|
||||
supported for the whole system, back in the days.
|
||||
|
||||
3. Consider allocating UID ranges for containers so that the first UID you
|
||||
assign has the lower 16bits all set to zero. That way, the upper 16bits become
|
||||
a container ID of some kind, while the lower 16bits directly encode the
|
||||
assign has the lower 16-bits all set to zero. That way, the upper 16-bits become
|
||||
a container ID of some kind, while the lower 16-bits directly encode the
|
||||
internal container UID. This is the way `systemd-nspawn` allocates UID ranges
|
||||
(see above). Following this allocation logic ensures best compatibility with
|
||||
`systemd-nspawn` and all other container managers following the scheme, as it
|
||||
@@ -212,7 +212,7 @@ as that's what they do, too. Moreover, it makes `chown()`ing container file
|
||||
system trees nicely robust to interruptions: as the external UID encodes the
|
||||
internal UID in a fixed way, it's very easy to adjust the container's base UID
|
||||
without the need to know the original base UID: to change the container base,
|
||||
just mask away the upper 16bit, and insert the upper 16bit of the new container
|
||||
just mask away the upper 16-bit, and insert the upper 16-bit of the new container
|
||||
base instead. Here are the easy conversions to derive the internal UID, the
|
||||
external UID, and the container base UID from each other:
|
||||
|
||||
@@ -264,17 +264,17 @@ i.e. somewhere below `/var/` or similar.
|
||||
| 6…999 | System users | Distributions | `/etc/passwd` |
|
||||
| 1000…60000 | Regular users | Distributions | `/etc/passwd` + LDAP/NIS/… |
|
||||
| 60001…60513 | Human users (homed) | `systemd` | `nss-systemd` |
|
||||
| 60514…60577 | Host users mapped into containers | `systemd` | `systemd-nspawn` |
|
||||
| 60514…60577 | Host users mapped into containers | `systemd` | `systemd-nspawn` |
|
||||
| 60578…61183 | Unused | | |
|
||||
| 61184…65519 | Dynamic service users | `systemd` | `nss-systemd` |
|
||||
| 65520…65533 | Unused | | |
|
||||
| 65534 | `nobody` user | Linux | `/etc/passwd` + `nss-systemd` |
|
||||
| 65535 | 16bit `(uid_t) -1` | Linux | |
|
||||
| 65535 | 16-bit `(uid_t) -1` | Linux | |
|
||||
| 65536…524287 | Unused | | |
|
||||
| 524288…1879048191 | Container UID ranges | `systemd` | `nss-systemd` |
|
||||
| 1879048192…2147483647 | Unused | | |
|
||||
| 2147483648…4294967294 | HIC SVNT LEONES | | |
|
||||
| 4294967295 | 32bit `(uid_t) -1` | Linux | |
|
||||
| 4294967295 | 32-bit `(uid_t) -1` | Linux | |
|
||||
|
||||
Note that "Unused" in the table above doesn't mean that these ranges are
|
||||
really unused. It just means that these ranges have no well-established
|
||||
@@ -285,7 +285,7 @@ ranges.
|
||||
Note that the range 2147483648…4294967294 (i.e. 2^31…2^32-2) should be handled
|
||||
with care. Various programs (including kernel file systems — see `devpts` — or
|
||||
even kernel syscalls – see `setfsuid()`) have trouble with UIDs outside of the
|
||||
signed 32bit range, i.e any UIDs equal to or above 2147483648. It is thus
|
||||
signed 32-bit range, i.e any UIDs equal to or above 2147483648. It is thus
|
||||
strongly recommended to stay away from this range in order to avoid
|
||||
complications. This range should be considered reserved for future, special
|
||||
purposes.
|
||||
|
||||
+27
-27
@@ -269,13 +269,13 @@ disposition of a user automatically from a record even in absence of this
|
||||
field, based on other fields, for example the numeric UID. By setting this
|
||||
field explicitly applications can override this default determination.
|
||||
|
||||
`lastChangeUSec` → An unsigned 64bit integer value, referring to a timestamp in µs
|
||||
`lastChangeUSec` → An unsigned 64-bit integer value, referring to a timestamp in µs
|
||||
since the epoch 1970, indicating when the user record (specifically, any of the
|
||||
`regular`, `privileged`, `perMachine` sections) was last changed. This field is
|
||||
used when comparing two records of the same user to identify the newer one, and
|
||||
is used for example for automatic updating of user records, where appropriate.
|
||||
|
||||
`lastPasswordChangeUSec` → Similar, also an unsigned 64bit integer value,
|
||||
`lastPasswordChangeUSec` → Similar, also an unsigned 64-bit integer value,
|
||||
indicating the point in time the password (or any authentication token) of the
|
||||
user was last changed. This corresponds to the `sp_lstchg` field of `struct
|
||||
spwd`, i.e. the matching field in the user shadow database `/etc/shadow`,
|
||||
@@ -338,7 +338,7 @@ i.e. logins are permitted. This field corresponds to the `sp_expire` field of
|
||||
`struct spwd` (i.e. the `/etc/shadow` data for a user) being set to zero or
|
||||
one.
|
||||
|
||||
`notBeforeUSec` → An unsigned 64bit integer value, indicating a time in µs since
|
||||
`notBeforeUSec` → An unsigned 64-bit integer value, indicating a time in µs since
|
||||
the UNIX epoch (1970) before which the record should be considered invalid for
|
||||
the purpose of logging in.
|
||||
|
||||
@@ -360,7 +360,7 @@ mounted from a Windows File Share. The five latter types are primarily used by
|
||||
`systemd-homed` when managing home directories, but may be used if other
|
||||
managers are used too. If this is not set, `classic` is the implied default.
|
||||
|
||||
`diskSize` → An unsigned 64bit integer, indicating the intended home directory
|
||||
`diskSize` → An unsigned 64-bit integer, indicating the intended home directory
|
||||
disk space in bytes to assign to the user. Depending on the selected storage
|
||||
type this might be implemented differently: for `luks` this is the intended size
|
||||
of the file system and LUKS volume, while for the others this likely translates
|
||||
@@ -378,7 +378,7 @@ directory is first created, and defaults to `/etc/skel` if not defined.
|
||||
`accessMode` → Takes an unsigned integer in the range 0…511 indicating the UNIX
|
||||
access mask for the home directory when it is first created.
|
||||
|
||||
`tasksMax` → Takes an unsigned 64bit integer indicating the maximum number of
|
||||
`tasksMax` → Takes an unsigned 64-bit integer indicating the maximum number of
|
||||
tasks the user may start in parallel during system runtime. This counts
|
||||
all tasks (i.e. threads, where each process is at least one thread) the user starts or that are
|
||||
forked from these processes even if the user identity is changed (for example
|
||||
@@ -387,7 +387,7 @@ by setuid binaries/`su`/`sudo` and similar).
|
||||
enforces this by setting the `TasksMax` slice property for the user's slice
|
||||
`user-$UID.slice`.
|
||||
|
||||
`memoryHigh`/`memoryMax` → These take unsigned 64bit integers indicating upper
|
||||
`memoryHigh`/`memoryMax` → These take unsigned 64-bit integers indicating upper
|
||||
memory limits for all processes of the user (plus all processes forked off them
|
||||
that might have changed user identity), in bytes. Enforced by
|
||||
[`systemd-logind.service`](https://www.freedesktop.org/software/systemd/man/systemd-logind.service.html),
|
||||
@@ -490,20 +490,20 @@ the PBKDF operation for the LUKS storage mechanism.
|
||||
|
||||
`luksPbkdfType` → A string, indicating the PBKDF type to use for the LUKS storage mechanism.
|
||||
|
||||
`luksPbkdfForceIterations` → An unsigned 64bit integer, indicating the intended
|
||||
`luksPbkdfForceIterations` → An unsigned 64-bit integer, indicating the intended
|
||||
number of iterations for the PBKDF operation, when LUKS storage is used.
|
||||
|
||||
`luksPbkdfTimeCostUSec` → An unsigned 64bit integer, indicating the intended
|
||||
`luksPbkdfTimeCostUSec` → An unsigned 64-bit integer, indicating the intended
|
||||
time cost for the PBKDF operation, when the LUKS storage mechanism is used, in
|
||||
µs. Ignored when `luksPbkdfForceIterations` is set.
|
||||
|
||||
`luksPbkdfMemoryCost` → An unsigned 64bit integer, indicating the intended
|
||||
`luksPbkdfMemoryCost` → An unsigned 64-bit integer, indicating the intended
|
||||
memory cost for the PBKDF operation, when LUKS storage is used, in bytes.
|
||||
|
||||
`luksPbkdfParallelThreads` → An unsigned 64bit integer, indicating the intended
|
||||
`luksPbkdfParallelThreads` → An unsigned 64-bit integer, indicating the intended
|
||||
required parallel threads for the PBKDF operation, when LUKS storage is used.
|
||||
|
||||
`luksSectorSize` → An unsigned 64bit integer, indicating the sector size to
|
||||
`luksSectorSize` → An unsigned 64-bit integer, indicating the sector size to
|
||||
use for the LUKS storage mechanism, in bytes. Must be a power of two between
|
||||
512 and 4096.
|
||||
|
||||
@@ -524,13 +524,13 @@ record. It is recommended to use reverse domain name notation for this. For
|
||||
example, if `systemd-homed` manages a user a string of `io.systemd.Home` is
|
||||
used for this.
|
||||
|
||||
`rateLimitIntervalUSec` → An unsigned 64bit integer that configures the
|
||||
`rateLimitIntervalUSec` → An unsigned 64-bit integer that configures the
|
||||
authentication rate limiting enforced on the user account. This specifies a
|
||||
timer interval (in µs) within which to count authentication attempts. When the
|
||||
counter goes above the value configured n `rateLimitIntervalBurst` log-ins are
|
||||
temporarily refused until the interval passes.
|
||||
|
||||
`rateLimitIntervalBurst` → An unsigned 64bit integer, closely related to
|
||||
`rateLimitIntervalBurst` → An unsigned 64-bit integer, closely related to
|
||||
`rateLimitIntervalUSec`, that puts a limit on authentication attempts within
|
||||
the configured time interval.
|
||||
|
||||
@@ -543,7 +543,7 @@ it is bypassed.
|
||||
auto-login. Systems are supposed to automatically log in a user marked this way
|
||||
during boot, if there's exactly one user on it defined this way.
|
||||
|
||||
`stopDelayUSec` → An unsigned 64bit integer, indicating the time in µs the
|
||||
`stopDelayUSec` → An unsigned 64-bit integer, indicating the time in µs the
|
||||
per-user service manager is kept around after the user fully logged out. This
|
||||
value is honored by
|
||||
[`systemd-logind.service`](https://www.freedesktop.org/software/systemd/man/systemd-logind.service.html). If
|
||||
@@ -557,17 +557,17 @@ automatically killed when the user logs out. This is enforced by
|
||||
[`systemd-logind.service`](https://www.freedesktop.org/software/systemd/man/systemd-logind.service.html). If
|
||||
false any processes left around when the user logs out are left running.
|
||||
|
||||
`passwordChangeMinUSec`/`passwordChangeMaxUSec` → An unsigned 64bit integer,
|
||||
`passwordChangeMinUSec`/`passwordChangeMaxUSec` → An unsigned 64-bit integer,
|
||||
encoding how much time has to pass at least/at most between password changes of
|
||||
the user. This corresponds with the `sp_min` and `sp_max` fields of `struct
|
||||
spwd` (i.e. the `/etc/shadow` entries of the user), but offers finer
|
||||
granularity.
|
||||
|
||||
`passwordChangeWarnUSec` → An unsigned 64bit integer, encoding how much time to
|
||||
`passwordChangeWarnUSec` → An unsigned 64-bit integer, encoding how much time to
|
||||
warn the user before their password expires, in µs. This corresponds with the
|
||||
`sp_warn` field of `struct spwd`.
|
||||
|
||||
`passwordChangeInactiveUSec` → An unsigned 64bit integer, encoding how much
|
||||
`passwordChangeInactiveUSec` → An unsigned 64-bit integer, encoding how much
|
||||
time has to pass after the password expired that the account is
|
||||
deactivated. This corresponds with the `sp_inact` field of `struct spwd`.
|
||||
|
||||
@@ -717,7 +717,7 @@ in full).
|
||||
|
||||
The following fields are defined in this section:
|
||||
|
||||
`matchMachineId` → An array of strings that are formatted 128bit IDs in
|
||||
`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.
|
||||
|
||||
@@ -799,26 +799,26 @@ sub-object of the top-level user record object is keyed by the machine ID,
|
||||
which points to the object with the fields defined here. The following fields
|
||||
are defined:
|
||||
|
||||
`diskUsage` → An unsigned 64bit integer. The currently used disk space of the
|
||||
`diskUsage` → An unsigned 64-bit integer. The currently used disk space of the
|
||||
home directory in bytes. This value might be determined in different ways,
|
||||
depending on the selected storage mechanism. For LUKS storage this is the file
|
||||
size of the loopback file or block device size. For the
|
||||
directory/subvolume/fscrypt storage this is the current disk space used as
|
||||
reported by the file system quota subsystem.
|
||||
|
||||
`diskFree` → An unsigned 64bit integer, denoting the number of "free" bytes in
|
||||
`diskFree` → An unsigned 64-bit integer, denoting the number of "free" bytes in
|
||||
the disk space allotment, i.e. usually the difference between the disk size as
|
||||
reported by `diskSize` and the used already as reported in `diskFree`, but
|
||||
possibly skewed by metadata sizes, disk compression and similar.
|
||||
|
||||
`diskSize` → An unsigned 64bit integer, denoting the disk space currently
|
||||
`diskSize` → An unsigned 64-bit integer, denoting the disk space currently
|
||||
allotted to the user, in bytes. Depending on the storage mechanism this can mean
|
||||
different things (see above). In contrast to the top-level field of the same
|
||||
(or the one in the `perMachine` section), this field reports the current size
|
||||
allotted to the user, not the intended one. The values may differ when user
|
||||
records are updated without the home directory being re-sized.
|
||||
|
||||
`diskCeiling`/`diskFloor` → Unsigned 64bit integers indicating upper and lower
|
||||
`diskCeiling`/`diskFloor` → Unsigned 64-bit integers indicating upper and lower
|
||||
bounds when changing the `diskSize` value, in bytes. These values are typically
|
||||
derived from the underlying data storage, and indicate in which range the home
|
||||
directory may be re-sized in, i.e. in which sensible range the `diskSize` value
|
||||
@@ -851,27 +851,27 @@ recognized by the local manager but whose private key is not available
|
||||
locally. This means the user record cannot be modified locally as it couldn't
|
||||
be signed afterwards.
|
||||
|
||||
`goodAuthenticationCounter` → An unsigned 64bit integer. This counter is
|
||||
`goodAuthenticationCounter` → An unsigned 64-bit integer. This counter is
|
||||
increased by one on every successful authentication attempt, i.e. an
|
||||
authentication attempt where a security token of some form was presented and it
|
||||
was correct.
|
||||
|
||||
`badAuthenticationCounter` → An unsigned 64bit integer. This counter is
|
||||
`badAuthenticationCounter` → An unsigned 64-bit integer. This counter is
|
||||
increased by one on every unsuccessfully authentication attempt, i.e. an
|
||||
authentication attempt where a security token of some form was presented and it
|
||||
was incorrect.
|
||||
|
||||
`lastGoodAuthenticationUSec` → An unsigned 64bit integer, indicating the time
|
||||
`lastGoodAuthenticationUSec` → An unsigned 64-bit integer, indicating the time
|
||||
of the last successful authentication attempt in µs since the UNIX epoch (1970).
|
||||
|
||||
`lastBadAuthenticationUSec` → Similar, but the timestamp of the last
|
||||
unsuccessfully authentication attempt.
|
||||
|
||||
`rateLimitBeginUSec` → An unsigned 64bit integer: the µs timestamp since the
|
||||
`rateLimitBeginUSec` → An unsigned 64-bit integer: the µs timestamp since the
|
||||
UNIX epoch (1970) where the most recent rate limiting interval has been
|
||||
started, as configured with `rateLimitIntervalUSec`.
|
||||
|
||||
`rateLimitCount` → An unsigned 64bit integer, counting the authentication
|
||||
`rateLimitCount` → An unsigned 64-bit integer, counting the authentication
|
||||
attempts in the current rate limiting interval, see above. If this counter
|
||||
grows beyond the value configured in `rateLimitBurst` authentication attempts
|
||||
are temporarily refused.
|
||||
|
||||
Reference in New Issue
Block a user