If it is null, we get the 'base' param unchanged:
$ build/systemd-id128 show 00000000000000000000000000000001 \
--app-specific=00000000000000000000000000000000
00000000000000000000000000000001
This is not good, because it breaks our promise that the base (usually either
machine-id or boot-id) cannot be derived from the result. Some application
using the library could use a null app id, inadvertently exposing the machine
or boot id. (This could happen because of forgotten initialization, or maybe
because the app id is configurable, and the user configures it wrongly.)
Note: the other way the secret is not exposed:
$ build/systemd-id128 show 00000000000000000000000000000000 \
--app-specific=00000000000000000000000000000002
4f63080959264900b0d88d999dae2d3a
Normally systemd would not allow a null machine-id or boot-id, but we can let
the user do the calculation that if they want to.
The enum definition, the two string tables and the test all were using
different orders (and in case of the test even missed entries).
Let's unify this, and make sure we always use the same order. This
settles the confusion, and makes the order used for the unicode string
table the canonical one, adjusting the other lists to match it. And adds
the missing entries to the tets.
We exported sd_id128_get_machine_app_specific() and
sd_id128_get_boot_app_specific(). But those operate on the current machine,
and sometimes the user might want to do the same calculation for a different
machine, or an earlier boot, etc. We expose the underlying implementation
to make this easy.
New directive `NFTSet=` provides a method for integrating network configuration
into firewall rules with NFT sets. The benefit of using this setting is that
static network configuration or dynamically obtained network addresses can be
used in firewall rules with the indirection of NFT set types. For example,
access could be granted for hosts in the local subnetwork only. Firewall rules
using IP address of an interface are also instantly updated when the network
configuration changes, for example via DHCP.
This option expects a whitespace separated list of NFT set definitions. Each
definition consists of a colon-separated tuple of source type (one of
"address", "prefix", or "ifindex"), NFT address family (one of "arp", "bridge",
"inet", "ip", "ip6", or "netdev"), table name and set name. The names of tables
and sets must conform to lexical restrictions of NFT table names. The type of
the element used in the NFT filter must match the type implied by the
directive ("address", "prefix" or "ifindex") and address type (IPv4 or IPv6)
as shown type implied by the directive ("address", "prefix" or "ifindex") and
address type (IPv4 or IPv6) must also match the set definition.
When an interface is configured with IP addresses, the addresses, subnetwork
masks or interface index will be appended to the NFT sets. The information will
be removed when the interface is deconfigured. systemd-networkd only inserts
elements to (or removes from) the sets, so the related NFT rules, tables and
sets must be prepared elsewhere in advance. Failures to manage the sets will be
ignored.
/etc/systemd/network/eth.network
```
[DHCPv4]
...
NFTSet=prefix:netdev:filter:eth_ipv4_prefix
```
Example NFT rules:
```
table netdev filter {
set eth_ipv4_prefix {
type ipv4_addr
flags interval
}
chain eth_ingress {
type filter hook ingress device "eth0" priority filter; policy drop;
ip saddr != @eth_ipv4_prefix drop
accept
}
}
```
```
$ sudo nft list set netdev filter eth_ipv4_prefix
table netdev filter {
set eth_ipv4_prefix {
type ipv4_addr
flags interval
elements = { 10.0.0.0/24 }
}
}
```
We so far maintained two places for symboic names for PCRs. One in
tpm2-util.h and one in tpm-pcr.h.
Let's unify this into one, i.e. move the full list from tpm2-util.h into
tpm-pcr.h, replacing the short list placed so far there.
Systematically prefix the definitions with TPM2_ or tpm2_, to follow how
we do this for all other defines in this context.
No change in behaviour, just unification of tables.
json_append() is a useful wrapper around json_variant_merge(). However,
I think the naming sould be cleaned up a bit of both functions.
I thinker "merge" is the better word than "append", since it does
decidedly more than just append: it replaces existing fields of the same
name, hence "merge" sounds more appropriate. This is as opposed to the
similar operations for arrays, where no such override logic is applied
and we really just append, hence those functions are called "append"
already.
To make clearer that "merge" is about objects, and "append" about
arrays, also include "object" in the name.
Also, include "json_variant" in the name, like we do for almost all
other functions in the JSON API that take a JSON object as primary
input, and hence are kinda object methods.
Finally, let's follow the logic that helpers that combine json_build()
with some other operation get suffixed with "b" like we already have in
some cases.
Hence:
json_variant_merge() → json_variant_merge_object()
json_append() → json_variant_merge_objectb()
This mirrors nicely the existing:
json_variant_append_array()
json_vairant_append_arrayb()
This also drops the variant of json_append() that takes a va_arg
parameter (i.e. json_appendv()). We have no user of that so far, and
given the nature as a helper function only I don#t see that happening,
and if it happens after all it's trivial to bring back.
Let's make utf8_to_utf16() and utf16_to_utf8() a bit nicer to use by
adding shortcuts for common cases.
This is particularly relevant for utf16_to_utf8() since the
multiplication with 2 is easy to forget.
Since kernel v5.2, open_tree() and move_mount() are added. If a service
loads or sets credentials, then let's try to clone the mount that contains
credentials with open_tree(), then mount it after a (private) mount
namespace is initialized for the service. Then, we can setup a mount for
credentials directory without leaking it to the main shared mount
namespace.
With this change, the credentials for services that request their own
private mount namespace become much much safer. And, the number of mount
events triggered by setting up credential directories can be decreased.
Unfortunately, this does not 'fix' the original issue #25527, as the
reported service does not requests private mount namespace, but the
situation should be better now.
"static inline" makes sense in .h files. But in .c files it's useless
decoration, the compiler should just make its own decisions there, and
it can do that.
hence, replace all remaining uses of "static line" by a simple" static"
in all .c files (but keep them in .h files, where they make sense)
seccomp-util.h doesn't need ifdeffing, hence don't. It has worked since
quite a while with HAVE_SECCOMP is off, hence use it everywhere.
Also drop explicit seccomp.h inclusion everywhere (which needs
HAVE_SECCOMP ifdeffery everywhere). seccomp-util.h includes it anyway,
automatically, which we can just rely on, and it deals with HAVE_SECCOMP
at one central place.
This is useful if the variable is ssize_t and we don't want to trigger a
warning or truncation.
With gcc (gcc-13.2.1-1.fc38.x86_64), the resulting systemd binary is identical,
so I assume that the compiler is able to completely optimize away the type.
We do 'IN_SET(r, -CONST1, -CONST2)', instead of 'IN_SET(-r, CONST1, CONST2)'
because -r is undefined if r is the minimum value (i.e. INT_MIN). But we know
that the constants are small, so their negative values are fine.
Currently, we mount via file descriptors using /proc/self/fd. This
works, but it means that in /proc/mounts and various other files,
the source of the mount will be listed as /proc/self/fd/xxx. For other
software that parses these files, /proc/self/fd/xxx doesn't mean anything,
or worse, it means the completely wrong thing, as it will refer to one of
their own file descriptors instead.
Let's improve the situation by using /proc/pid/fd instead. This allows
processes parsing /proc/mounts to do the right thing more often than not.
One scenario where even this doesn't work if when containers are involved,
as with the pid namespace unshared, even /proc/pid/fd will mean the wrong
thing, but it's no worse than /proc/self/fd which will always means the wrong
thing.
This also doesn't work if we mount via file descriptor and then exit, as the pid will
be gone, but it does work as long as the process that did the mount is alive, which
makes it useful for systemd-dissect --with for example if the program we run in the
image wants to parse /proc/mounts.
The subvolumes set is a set of source inodes similar to how the
denylist hashmap contains source inodes as keys. It indicates
directories in the source tree that should become subvolumes in
the target tree.
Salsa is the Debian git forge. In the package build environment test-path
always fails as we cannot set up cgroups and so the path unit fails to
start. Skip the test in that environment.
Unfortunately meson doesn't allow to skip individual tests by name.
This change makes sure a data copy using copy_bytes() does not exceed the
max_bytes value when using COPY_HOLES and max_bytes stops before the next
data section.
Add a macro to log all errors in the openssl 'thread error queue'.
This consolidates all the openssl-generated errors to return -EIO and log at
debug level.
Also add a 'invalid' test in test-openssl, to allow manual verification that
the openssl error(s) are logged.
Add functions to convert a PEM or pkey to TPM2B_PUBLIC, and functions to
convert TPM2B_PUBLIC to pkey or fingerprint.
Supports both RSA and ECC keys.
Add ECC support to some test-tpm2 tests, and tests to cover the newly added functions.
In order to allow users to specify expected PCR values, change the
tpm2_parse_pcr_argument() to parse the text argument into an array of
Tpm2PCRValue objects, which provide not only the selected PCR indexes, but also
(optionally) the hash algorithm and hash value for each PCR index.
Mike Yuan
Zbigniew Jędrzejewski-Szmek
Yu Watanabe
Lennart Poettering
Luca Boccassi
Topi Miettinen
Daan De Meyer
David Tardon
Michael A Cassaniti
Franck Bui
Xiaotian Wu
Dan Streetman