Let's beef up our parser a bit: let's store in the DnsAnswerFlags field
(that is stored as part of DnsAnswerItem) which DNS packet section (i.e.
answer, authoritative, additional) an RR originates from.
This is useful when propagating answers from an upstream DNS server
eventually, as we can place the data in the right sections downstream
too.
The more fields DnsAnswerItem gains the less sense it makes to pass
every field of it as separate parameter to an iterator macro. Let's
simplify things here, in preparation of adding more fields to the
structure later on: let's just return the structure itself in the loop,
rather than the individual fields.
This is a simple search&replace excercise: instead of accessing the
"key" field of the transaction directly, let's use a small inline helper
that does this for us.
This appears pointless for now, but this will become useful later when
we introduce "bypass" transactions, that reuse the original client DNS
packet for queries instead of synthesizing a packet of our own. In that
case transactions either have regular "key" field initialized as before,
or the "bypass" packet field instead. The new dns_transaction_key()
helper allows us to hide the differences for most cases as we can later
teach it to access the "bypass" packet's question key transparently.
No change in behaviour.
systemd-inhibit when invoked with a command line will put the whole
command line in the "who" field of the inhibitor lock. This can get
extremely long for shell expressions, making the table "systemd-inhibit
--list" shows ridiculously weirdly formatted. Let's put a limit on the
column width: half of the screen, not more.
If one field in a specific column has a maximum size limit, other fields
in the same column might affected by it and get less than they asked
for. Let's make sure we can handle this, and don't assert on this
because surprisingly we got less than what we asked for.
Does what the name suggests. Obviously inspired by sudoers, but note that
our tools are not supposed to be installed suid, so there is no privilege
boundary to cross here.
We have a number of issues where oss-fuzz reports input-independent crashes of
fuzz-journal-remote. Instead of asserting that stuff that allocated fds and
memory never fails, let's instead just return an error.
https://oss-fuzz.com/testcase-detail/4791099424112640https://oss-fuzz.com/testcase-detail/4531912477638656
I don't see any docs as to whether LLVMFuzzerTestOneInput() is allowed to
return non-zero. Propagating the error code is easiest, so let's just do that.
If it turns out that this causes oss-fuzz to still report a failure, we can
suppress that later.
glibc 2.33-3 shipped on 2021-02-06 breaks running Arch containers on
systems with older kernels (like Ubuntu Focal). Until the issue is
resolved, let's pin the Arch repositories to glibc 2.32-5 to mitigate
the annoying CI fails.
See: https://bugs.archlinux.org/task/69563
Setting of IPv6 Proxy NDP addresses must be done at the same
time as static addresses, static routes, and other link attributes
that must be configured when the link is up. Doing this ensures
that they are reconfigured on the link if the link goes down
and returns to service.
There may be situations where a cgroup should be protected from killing
or deprioritized as a candidate. In FB oomd xattrs are used to bias oomd
away from supervisor cgroups and towards worker cgroups in container
tasks. On desktops this can be used to protect important units with
unpredictable resource consumption.
The patch allows systemd-oomd to understand 2 xattrs:
"user.oomd_avoid" and "user.oomd_omit". If systemd-oomd sees these
xattrs set to 1 on a candidate cgroup (i.e. while attempting to kill something)
AND the cgroup is owned by root, it will either deprioritize the cgroup as
a candidate (avoid) or remove it completely as a candidate (omit).
Usage is restricted to root owned cgroups to prevent situations where an
unprivileged user can set their own cgroups lower in the kill priority than
another user's (and prevent them from omitting their units from
systemd-oomd killing).
Unfortunately, strverscmp() from libc or str_verscmp() do not correctly
handle pre-release version, e.g. 247 vs 247~rc1.
This implement a new comparison function, which is based on the RPM's
rpmvercmp().
sd-boot has a copy of a subset of codes from libbasic. This makes
sd-boot share the code with libbasic, and dedup the code.
Note, startswith_no_case() is dropped from sd-boot, as
- it is not used,
- the previous implementation is not correct,
- gnu-efi does not have StrniCmp() or so.
Previously, even when writing e.g. /etc/hostname fails, the static
hostname in Context is not restored. So, the subsequent call of the same
method succeeds:
```
$ sudo chattr +i /etc/hostname
$ sudo hostnamectl --static set-hostname aaa
Could not set static hostname: Access denied
$ echo $?
1
$ sudo hostnamectl --static set-hostname aaa
$ echo $?
0
```
This makes when updating file is failed, the saved stat is cleared. So,
the static hostname or machine information in the context are always
consistent to the corresponding files.
If no target (--pretty, --static, or --transient) is specified, then
let's try to set transient hostname even if setting static or pretty
hostname failed. This may be useful for read-only filesystem.
e.g.:
./src/shared/dissect-image.c:2218:39: error: suspicious concatenation of string literals in an array initialization; did you mean to separate the elements with a comma? [-Werror,-Wstring-concatenation]
"/usr/lib/os-release\0",
^
../src/shared/dissect-image.c:2217:39: note: place parentheses around the string literal to silence warning
[META_OS_RELEASE] = "/etc/os-release\0"
^
1 error generated.
See: https://reviews.llvm.org/D85545
As far as I can see, at some point the parser function for MountAPIVFS
was changed from the generic bool parser to a custom implementation, to
allow the context to keep track of whether MountAPIVFS had been set
explicitly. If not, exec_context_get_effective_mount_apivfs would fall
back to a default value. However, the corresponding entry in the big
parser table wasn't updated, meaning that the old bool parser was still
used, meaning that context->mount_apivfs_set remained at its default
value of false, meaning that the default value was always used and the
config option was effectively ignored.
Fix for 5e98086d16.
The last release of Upstart was July 2014 [1], and there have been no new
commits to the repo. We should move on too.
[1] https://lists.ubuntu.com/archives/upstart-devel/2014-July/003313.html
The only real support was in the code that looked for $PREVLEVEL.
https://codesearch.debian.net/search?q=PREVLEVEL&literal=1&perpkg=1 shows this
string in our own code (or the copy in elogind), our own man pages, and init
scripts for two packages (brltty, salt), which shouldn't be used with systemd.
(And both *check* for PREVLEVEL, and don't set it. So most likely nothing at
all sets it.)
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Yu Watanabe
Frantisek Sumsal
Kevin P. Fleming
Anita Zhang
Gablegritule
Antonius Frie
cprn