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.
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 might inherit a max rlim value that's larger than the kernel's
maximum (nr_open). This will cause setrlimit() to fail as the given
maximum is larger than the kernel's maximum. To get around this,
let's limit the max rlim we pass to rlimit() to the value of nr_open.
Should fix#28965
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.
"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)
Let's make sure btrfs_subvol_make() can operate on O_PATH fds, just like
mkdirat().
Fixes a bunch of tmpfiles errors at boot if we try to create btrfs
subvols, introduced by e54c79ccc2
Fixes: e54c79ccc2
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.
This reverts commit 1483892a42.
As the commit says, it does not solve the race. Moreover, it introduces
an regression #28410.
Also, checking by `path_is_mount_point()` may trigger automount. From
statx(2),
> AT_NO_AUTOMOUNT
> Don't automount the terminal ("basename") component of pathname
> if it is a directory that is an automount point.
Similar statements can be found in fstatat(2), which is used in the
fallback call for statx() in glibc, and name_to_handle_at(2), which is
used as the fallback when statx() failed.
So, `path_is_mount_point()` may _do_ trigger automount for parent paths.
That should be avoided especially on shutdown.
The original issue #25527 that is 'fixed' by the commit is not serious,
and should be fixed by making umount command handle path gracefully:
https://github.com/util-linux/util-linux/issues/2132Fixes#28410.
This is supposed to be a help for compilers to apply optimizations on
functions where they can't determine whether they are const/pure on
their own. For static, local functions the compiler can do this on its
own easily however, hence the decoration with pure/const is just noise.
Let's drop it, and let the compiler to its thing better.
(Use it for exported functions, since compilers can't 'reach-over' into
other modules to determine if they are pure, except if LTO is used)
Add function to create openssl pkey from ECC curve and point, and function to
get curve id and x/y point from existing ECC pkey. Also add function to create
new ECC key for specified curve.
Also add DEFINE_TRIVIAL_CLEANUP_FUNC_FULL_MACRO() to handle case when func() is
a macro, not a function symbol; specifically in this case it is used for
OPENSSL_free() which is a macro.
Fixes
| ../git/src/basic/user-util.c:708:30: error: use of undeclared identifier 'LOCK_EX'; did you mean 'LOCK_BSD'?
| 708 | r = unposix_lock(fd, LOCK_EX);
| | ^~~~~~~
| | LOCK_BSD
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Private mappings are required when F_SEAL_WRITE is set on a memfd,
because otherwise you could end up with writable mappings through
mprotect() and other calls. This is a limitation of the kernel
implementation, and might be lifted by future extensions.
Regardless, the current code tests for the full `is_sealed()` before
using MAP_PRIVATE. This might end up using MAP_SHARED for write-sealed
memfds, which will be refused by the kernel.
Fix this and make memfd_map() check for exactly `F_SEAL_WRITE`.
Rather than always setting all seals, make `memfd_set_seals()` employ
the original set of seals, that is: SEAL+GROW+SHRINK+WRITE
Historically, the memfd code was used with the out-of-tree memfd
patches, which merely supported a single seal ("SEALED", which
effectively was GROW+SHRINK+WRITE). When the code was adapted to the
upstream memfd seals, it was extended to the full seal set. With more
and more seals being added upstream, this because more problematic. In
particular, it is unclear what the function really is meant to achieve.
Instead of just adding all seals, the function is returned to its
original purpose: seal the memfd so futher modifications to its content
are prevented.
With `F_SEAL_SEAL` a memfd can disable further sealing operations,
effectively sealing the set of seals. Testing for it ensures that no
further seals can be added, it never prevents seals from being dropped,
since seals cannot be dropped, ever.
Now testing for `F_SEAL_SEAL` makes sense if you want to ensure that
some seals are *not* set. That is, you either test for the entire set of
seals to match a local set, or you verify that a specific seal is not
set. Neither is what we are doing, so it feels wrong requiring it to be
set.
By dropping the requirement for `F_SEAL_SEAL`, the same FD can be shared
with other entities while retaining the ability to further restrict the
set of seals later on (e.g., being able to mark a region as executable
later on, and then adding `F_SEAL_EXEC`).
OMOJOLA JOSHUA
Yu Watanabe
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
Topi Miettinen
Daan De Meyer
Luca Boccassi
David Tardon
Sam James
Mike Yuan
Xiaotian Wu
Dan Streetman
Khem Raj
David Rheinsberg