mirror of
https://github.com/Dasharo/systemd.git
synced 2026-03-06 15:02:31 -08:00
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
24
NEWS
24
NEWS
@@ -1173,7 +1173,7 @@ CHANGES WITH 253:
|
||||
sd_bus_emit_signal_tov(), and sd_bus_message_new_signal_to().
|
||||
|
||||
* sd-id128 functions now return -EUCLEAN (instead of -EIO) when the
|
||||
128bit ID in files such as /etc/machine-id has an invalid
|
||||
128-bit ID in files such as /etc/machine-id has an invalid
|
||||
format. They also accept NULL as output parameter in more places,
|
||||
which is useful when the caller only wants to validate the inputs and
|
||||
does not need the output value.
|
||||
@@ -1568,7 +1568,7 @@ CHANGES WITH 252 🎃:
|
||||
|
||||
* libsystemd now exports sd_bus_error_setfv() (a convenience function
|
||||
for setting bus errors), sd_id128_string_equal (a convenience
|
||||
function for 128bit ID string comparisons), and
|
||||
function for 128-bit ID string comparisons), and
|
||||
sd_bus_message_read_strv_extend() (a function to incrementally read
|
||||
string arrays).
|
||||
|
||||
@@ -2030,7 +2030,7 @@ CHANGES WITH 251:
|
||||
of activated home directories it manages (if the kernel and selected
|
||||
file systems support it). So far it mapped three UID ranges: the
|
||||
range from 0…60000, the user's own UID, and the range 60514…65534,
|
||||
leaving everything else unmapped (in other words, the 16bit UID range
|
||||
leaving everything else unmapped (in other words, the 16-bit UID range
|
||||
is mapped almost fully, with the exception of the UID subrange used
|
||||
for systemd-homed users, with one exception: the user's own UID).
|
||||
Unmapped UIDs may not be used for file ownership in the home
|
||||
@@ -5894,7 +5894,7 @@ CHANGES WITH 245:
|
||||
systemd-timedated.
|
||||
|
||||
* The systemd-id128 tool gained a new "show" verb for listing or
|
||||
resolving a number of well-known UUIDs/128bit IDs, currently mostly
|
||||
resolving a number of well-known UUIDs/128-bit IDs, currently mostly
|
||||
GPT partition table types.
|
||||
|
||||
* The Discoverable Partitions Specification has been updated to support
|
||||
@@ -6174,7 +6174,7 @@ CHANGES WITH 244:
|
||||
path as the system manager.
|
||||
|
||||
* The systemd-id128 tool gained a new switch "-u" (or "--uuid") for
|
||||
outputting the 128bit IDs in UUID format (i.e. in the "canonical
|
||||
outputting the 128-bit IDs in UUID format (i.e. in the "canonical
|
||||
representation").
|
||||
|
||||
* Service units gained a new sandboxing option ProtectKernelLogs= which
|
||||
@@ -6242,7 +6242,7 @@ CHANGES WITH 243:
|
||||
|
||||
* On 64 bit systems, the "kernel.pid_max" sysctl is now bumped to
|
||||
4194304 by default, i.e. the full 22bit range the kernel allows, up
|
||||
from the old 16bit range. This should improve security and
|
||||
from the old 16-bit range. This should improve security and
|
||||
robustness, as PID collisions are made less likely (though certainly
|
||||
still possible). There are rumours this might create compatibility
|
||||
problems, though at this moment no practical ones are known to
|
||||
@@ -6557,7 +6557,7 @@ CHANGES WITH 243:
|
||||
with gcc's cleanup extension.
|
||||
|
||||
* The sd-id128.h public API gained a new definition
|
||||
SD_ID128_UUID_FORMAT_STR for formatting a 128bit ID in UUID format
|
||||
SD_ID128_UUID_FORMAT_STR for formatting a 128-bit ID in UUID format
|
||||
with printf().
|
||||
|
||||
* "busctl introspect" gained a new switch --xml-interface for dumping
|
||||
@@ -7337,7 +7337,7 @@ CHANGES WITH 240:
|
||||
ID.
|
||||
|
||||
* A new tool systemd-id128 has been added that can be used to determine
|
||||
and generate various 128bit IDs.
|
||||
and generate various 128-bit IDs.
|
||||
|
||||
* /etc/os-release gained two new standardized fields DOCUMENTATION_URL=
|
||||
and LOGO=.
|
||||
@@ -7492,7 +7492,7 @@ CHANGES WITH 240:
|
||||
is improved.
|
||||
|
||||
* sd-id128.h learnt two new auxiliary helpers: sd_id128_is_allf() and
|
||||
SD_ID128_ALLF to test if a 128bit ID is set to all 0xFF bytes, and to
|
||||
SD_ID128_ALLF to test if a 128-bit ID is set to all 0xFF bytes, and to
|
||||
initialize one to all 0xFF.
|
||||
|
||||
* After loading the SELinux policy systemd will now recursively relabel
|
||||
@@ -9219,9 +9219,9 @@ CHANGES WITH 233:
|
||||
Verity root partitions when systemd boots up. In order to make use of
|
||||
this your partition setup should follow the Discoverable Partitions
|
||||
Specification, and the GPT partition ID of the root file system
|
||||
partition should be identical to the upper 128bit of the Verity root
|
||||
partition should be identical to the upper 128-bit of the Verity root
|
||||
hash. The GPT partition ID of the Verity partition protecting it
|
||||
should be the lower 128bit of the Verity root hash. If the partition
|
||||
should be the lower 128-bit of the Verity root hash. If the partition
|
||||
image follows this model it is sufficient to specify a single
|
||||
"roothash=" kernel command line argument to both configure which root
|
||||
image and verity partition to use as well as the root hash for
|
||||
@@ -9654,7 +9654,7 @@ CHANGES WITH 232:
|
||||
|
||||
* The service manager learnt a new "invocation ID" concept for invoked
|
||||
services. Each runtime cycle of a service will get a new invocation
|
||||
ID (a 128bit random UUID) assigned that identifies the current
|
||||
ID (a 128-bit random UUID) assigned that identifies the current
|
||||
run of the service uniquely and globally. A new invocation ID
|
||||
is generated each time a service starts up. The journal will store
|
||||
the invocation ID of a service along with any logged messages, thus
|
||||
|
||||
@@ -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`,
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -86,7 +86,7 @@
|
||||
<listitem><para>The maximum size in bytes of a core which will be processed. Core dumps exceeding
|
||||
this size may be stored, but the backtrace will not be generated. Like other sizes in this same
|
||||
config file, the usual suffixes to the base of 1024 are allowed (B, K, M, G, T, P, and E). Defaults
|
||||
to 1G on 32bit systems, 32G on 64bit systems.</para>
|
||||
to 1G on 32-bit systems, 32G on 64-bit systems.</para>
|
||||
|
||||
<para>Setting <varname>Storage=none</varname> and <varname>ProcessSizeMax=0</varname>
|
||||
disables all coredump handling except for a log entry.</para>
|
||||
|
||||
@@ -76,13 +76,13 @@
|
||||
<listitem><para>The GPT partition type UUID to match. This may be a GPT partition type UUID such as
|
||||
<constant>4f68bce3-e8cd-4db1-96e7-fbcaf984b709</constant>, or an identifier.
|
||||
Architecture specific partition types can use one of these architecture identifiers:
|
||||
<constant>alpha</constant>, <constant>arc</constant>, <constant>arm</constant> (32bit),
|
||||
<constant>arm64</constant> (64bit, aka aarch64), <constant>ia64</constant>,
|
||||
<constant>alpha</constant>, <constant>arc</constant>, <constant>arm</constant> (32-bit),
|
||||
<constant>arm64</constant> (64-bit, aka aarch64), <constant>ia64</constant>,
|
||||
<constant>loongarch64</constant>, <constant>mips-le</constant>, <constant>mips64-le</constant>,
|
||||
<constant>parisc</constant>, <constant>ppc</constant>, <constant>ppc64</constant>,
|
||||
<constant>ppc64-le</constant>, <constant>riscv32</constant>, <constant>riscv64</constant>,
|
||||
<constant>s390</constant>, <constant>s390x</constant>, <constant>tilegx</constant>,
|
||||
<constant>x86</constant> (32bit, aka i386) and <constant>x86-64</constant> (64bit, aka amd64).
|
||||
<constant>x86</constant> (32-bit, aka i386) and <constant>x86-64</constant> (64-bit, aka amd64).
|
||||
|
||||
The supported identifiers are:</para>
|
||||
|
||||
@@ -158,7 +158,7 @@
|
||||
|
||||
<row>
|
||||
<entry><constant>root-secondary</constant></entry>
|
||||
<entry>Root file system partition of the secondary architecture of the local architecture (usually the matching 32bit architecture for the local 64bit architecture)</entry>
|
||||
<entry>Root file system partition of the secondary architecture of the local architecture (usually the matching 32-bit architecture for the local 64-bit architecture)</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
@@ -203,7 +203,7 @@
|
||||
|
||||
<row>
|
||||
<entry><constant>usr-secondary</constant></entry>
|
||||
<entry><filename>/usr/</filename> file system partition of the secondary architecture of the local architecture (usually the matching 32bit architecture for the local 64bit architecture)</entry>
|
||||
<entry><filename>/usr/</filename> file system partition of the secondary architecture of the local architecture (usually the matching 32-bit architecture for the local 64-bit architecture)</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
@@ -572,7 +572,7 @@
|
||||
<varlistentry>
|
||||
<term><varname>Flags=</varname></term>
|
||||
|
||||
<listitem><para>Configures the 64bit GPT partition flags field to set for the partition when creating
|
||||
<listitem><para>Configures the 64-bit GPT partition flags field to set for the partition when creating
|
||||
it. This option has no effect if the partition already exists. If not specified the flags values is
|
||||
set to all zeroes, except for the three bits that can also be configured via
|
||||
<varname>NoAuto=</varname>, <varname>ReadOnly=</varname> and <varname>GrowFileSystem=</varname>; see
|
||||
|
||||
@@ -111,7 +111,7 @@
|
||||
other event sources or at event loop termination. See
|
||||
<citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
|
||||
|
||||
<listitem><para>Event sources may be assigned a 64bit priority
|
||||
<listitem><para>Event sources may be assigned a 64-bit priority
|
||||
value, that controls the order in which event sources are
|
||||
dispatched if multiple are pending simultaneously. See
|
||||
<citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
|
||||
|
||||
@@ -47,7 +47,7 @@
|
||||
<function>sd_bus_get_n_queued_read()</function> may be used to query the number of bus messages in the read queue
|
||||
of a bus connection object. The read queue contains all messages read from the transport medium (e.g. network
|
||||
socket) but not yet processed locally. The function expects two arguments: the bus object to query, and a pointer
|
||||
to a 64bit counter variable to write the current queue size to. Use <function>sd_bus_process()</function> in
|
||||
to a 64-bit counter variable to write the current queue size to. Use <function>sd_bus_process()</function> in
|
||||
order to process queued messages, i.e. to reduce the size of the read queue (as well as, in fact, the write
|
||||
queue, see below).
|
||||
</para>
|
||||
|
||||
@@ -87,7 +87,7 @@
|
||||
<row>
|
||||
<entry><literal>y</literal></entry>
|
||||
<entry><constant>SD_BUS_TYPE_BYTE</constant></entry>
|
||||
<entry>8bit unsigned integer</entry>
|
||||
<entry>8-bit unsigned integer</entry>
|
||||
<entry><type>uint8_t *</type></entry>
|
||||
</row>
|
||||
|
||||
@@ -101,42 +101,42 @@
|
||||
<row>
|
||||
<entry><literal>n</literal></entry>
|
||||
<entry><constant>SD_BUS_TYPE_INT16</constant></entry>
|
||||
<entry>16bit signed integer</entry>
|
||||
<entry>16-bit signed integer</entry>
|
||||
<entry><type>int16_t *</type></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><literal>q</literal></entry>
|
||||
<entry><constant>SD_BUS_TYPE_UINT16</constant></entry>
|
||||
<entry>16bit unsigned integer</entry>
|
||||
<entry>16-bit unsigned integer</entry>
|
||||
<entry><type>uint16_t *</type></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><literal>i</literal></entry>
|
||||
<entry><constant>SD_BUS_TYPE_INT32</constant></entry>
|
||||
<entry>32bit signed integer</entry>
|
||||
<entry>32-bit signed integer</entry>
|
||||
<entry><type>int32_t *</type></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><literal>u</literal></entry>
|
||||
<entry><constant>SD_BUS_TYPE_UINT32</constant></entry>
|
||||
<entry>32bit unsigned integer</entry>
|
||||
<entry>32-bit unsigned integer</entry>
|
||||
<entry><type>uint32_t *</type></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><literal>x</literal></entry>
|
||||
<entry><constant>SD_BUS_TYPE_INT64</constant></entry>
|
||||
<entry>64bit signed integer</entry>
|
||||
<entry>64-bit signed integer</entry>
|
||||
<entry><type>int64_t *</type></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><literal>t</literal></entry>
|
||||
<entry><constant>SD_BUS_TYPE_UINT64</constant></entry>
|
||||
<entry>64bit unsigned integer</entry>
|
||||
<entry>64-bit unsigned integer</entry>
|
||||
<entry><type>uint64_t *</type></entry>
|
||||
</row>
|
||||
|
||||
|
||||
@@ -56,7 +56,7 @@
|
||||
<para><function>sd_event_source_set_priority()</function> may be
|
||||
used to set the priority for the event source object specified as
|
||||
<parameter>source</parameter>. The priority is specified as an
|
||||
arbitrary signed 64bit integer. The priority is initialized to
|
||||
arbitrary signed 64-bit integer. The priority is initialized to
|
||||
<constant>SD_EVENT_PRIORITY_NORMAL</constant> (0) when the event
|
||||
source is allocated with a call such as
|
||||
<citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
@@ -70,7 +70,7 @@
|
||||
<constant>SD_EVENT_PRIORITY_IDLE</constant> (100) may be used to
|
||||
indicate event sources that shall be dispatched early, normally or
|
||||
late. It is recommended to specify priorities based on these
|
||||
definitions, and relative to them — however, the full 64bit
|
||||
definitions, and relative to them — however, the full 64-bit
|
||||
signed integer range is available for ordering event
|
||||
sources.</para>
|
||||
|
||||
|
||||
@@ -121,7 +121,7 @@
|
||||
of the states described below.</para>
|
||||
|
||||
<para><function>sd_event_get_iteration()</function> may be used to determine the current iteration of the event
|
||||
loop. It returns an unsigned 64bit integer containing a counter that increases monotonically with each iteration of
|
||||
loop. It returns an unsigned 64-bit integer containing a counter that increases monotonically with each iteration of
|
||||
the event loop, starting with 0. The counter is increased at the time of the
|
||||
<function>sd_event_prepare()</function> invocation.</para>
|
||||
|
||||
|
||||
@@ -71,7 +71,7 @@
|
||||
a string representation of a 128-bit ID in a buffer that is valid in the current code block.</para>
|
||||
|
||||
<para><function>sd_id128_to_uuid_string()</function> and <function>SD_ID128_TO_UUID_STRING()</function>
|
||||
are similar to these two functions/macros, but format the 128bit values as RFC4122 UUIDs, i.e. a series
|
||||
are similar to these two functions/macros, but format the 128-bit values as RFC4122 UUIDs, i.e. a series
|
||||
of 36 lowercase hexadeciaml digits and dashes, terminated by a <constant>NUL</constant> byte.</para>
|
||||
|
||||
<para><function>sd_id128_from_string()</function> implements the reverse operation: it takes a 33
|
||||
|
||||
@@ -39,11 +39,11 @@
|
||||
|
||||
<para><function>sd_journal_get_seqnum()</function> returns the sequence number of the current journal
|
||||
entry. It takes three arguments: the journal context object, a pointer to a 64-bit unsigned integer to
|
||||
store the sequence number in, and a buffer to return the 128bit sequence number ID in.</para>
|
||||
store the sequence number in, and a buffer to return the 128-bit sequence number ID in.</para>
|
||||
|
||||
<para>When writing journal entries to disk each <command>systemd-journald</command> instance will number
|
||||
them sequentially, starting from 1 for the first entry written after subsystem initialization. Each such
|
||||
series of sequence numbers is associated with a 128bit sequence number ID which is initialized randomly,
|
||||
series of sequence numbers is associated with a 128-bit sequence number ID which is initialized randomly,
|
||||
once at <command>systemd-journal</command> initialization. Thus, while multiple instances of
|
||||
<command>systemd-journald</command> will assign the same sequence numbers to their written journal
|
||||
entries, they will have a distinct sequence number IDs. The sequence number is assigned at the moment of
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user