Back in 08318a2c5acb3d0e4243c36461e69a3e45482441, value "false" was enabled for
'-Dtests=', but various tests were not conditionalized properly. So even with
-Dtests=false -Dslow-tests=false we'd run 120 tests. Let's make this consistent.
meson: disable "slow tests" too when tests are generally disabled
We would have a strange situation where after setting -Dslow-tests=true -Dtests=false
we'd get mostly the slow tests (plus some other ones which I'll fix in
subsequent commit). Let's simplify things by making -Dtests=false just
disable those tests too.
test: use ${builddir}/systemd-runtest.env for $SYSTEMD_CATALOG_DIR
This makes it so that tests no longer need to know the absolute paths to the
source and build dirs, instead using the systemd-runtest.env file to get these
paths when running from the build tree.
Confirmed that test-catalog works on `ninja test`, when called standalone and
also when the environment file is not present, in which case it will use the
installed location under /usr/lib/systemd/catalog.
The location can now also be overridden for this test by setting the
$SYSTEMD_CATALOG_DIR environment variable.
test: use ${builddir}/systemd-runtest.env to set $SYSTEMD_TEST_DATA
This simplifies get_testdata_dir() to simply checking for an environment
variable, with an additional function to locate a systemd-runtest.env file in
the same directory as the test binary and reading environment variable
assignments from that file if it exists.
This makes it possible to:
- Run `ninja test` from the build dir and have it use ${srcdir}/test for
test unit definitions.
- Run a test directly, such as `build/test-execute` and have it locate
them correctly.
- Run installed tests (from systemd-tests package) and locate the test
units in the installed location (/usr/lib/systemd/tests/testdata), in
which case the absence of the systemd-runtest.env file will have
get_testdata_dir() use the installed location hardcoded into the
binaries.
Explicit setting of $SYSTEMD_TEST_DATA still overrides the contents of
systemd-runtest.env.
This also unifies __filter_units_by_property() and
__filter_units_by_properties(), and makes completion for 'restart',
'reload' or 'stop' show more candidates.
systemctl: correctly proceed to immediate shutdown if scheduling fails
Actually check the return code from logind_schedule_shutdown() and proceed to
immediate shutdown if that fails. Negative return codes can be returned if
systemctl is compiled without logind support, or if logind otherwise failed
(either too old, disabled/masked, or it is incomplete
systemd-shim/systemd-service implementation).
In that case, the arp-type and MAC address is still unset. Note that
dhcp_network_bind_raw_socket() already checks for a valid arp-type
and MAC address below, so we should just gracefully return -EINVAL.
Maybe sd_dhcp_client_start() should fail earlier when starting without
MAC address. But the failure here will be correctly propagated and
the start aborted.
We already carry a requirement for meson_version : '>= 0.46', so we can be sure
our build system will include this commit.
Tested by building systemd using a cloned meson synced to the 0.46.0 tag,
confirmed the warnings were detected correctly in that case. The meson messages included this snippet:
> Compiler for C supports arguments -Wno-unused-parameter -Wunused-parameter: YES
> Compiler for C supports arguments -Wno-missing-field-initializers -Wmissing-field-initializers: YES
> Compiler for C supports arguments -Wno-unused-result -Wunused-result: YES
> Compiler for C supports arguments -Wno-format-signedness -Wformat-signedness: YES
> Compiler for C supports arguments -Wno-error=nonnull -Werror=nonnull: YES
> Compiler for C supports arguments -Wno-maybe-uninitialized -Wmaybe-uninitialized: YES
The GitHub guide on contributing file says: "Decide whether to store your
contributing guidelines in your repository's root, docs, or .github directory."
The docs/ directory is special in GitHub, since it can be used to serve GitHub
Pages from, so there's a benefit to switching to it in order to expose it
directly as a website.
Updated references to it from the documentations themselves, from the
CONTRIBUTING.md file and from Meson build files.
Compiler flag -Wmaybe-uninitialized is quite noisy and produces many false
positives, especially when optimization flags are enabled (tested gcc 8.2.1),
so let's just disable it in systemd build.
For example, with CFLAGS=-O2, the build produces 11 such warnings and the
default CFLAGS of Fedora's rpmbuild warns about it in 176 places. A look at a
sample of those shows that most are false positives, where the compiler just
can't figure it out correctly. (While fixing those would be nice, I'm not sure
it's a good use of our time.)
The noisy [-Wmaybe-uninitialized] warnings are not just an annoyance, since
they make it harder to spot warnings that indicate actual problems (such as
variable declared but not used.) Silencing those is beneficial, so that
contributors would see warnings where there are actually actionable problems,
so there's a better chance of having those issues addressed before a PR is
pushed.
With the commands above, the build will not produce any [-Wmaybe-uninitialized]
warnings (or any other warnings), which is not really the case before this commit.
Also tested with rpmbuild on Fedora, after this commit there are no warnings
produced in the build step.
seccomp: permit specifying multiple errnos for a syscall
If more than one errno is specified for a syscall in SystemCallFilter=,
use the last one instead of reporting an error. This is especially
useful when used with system call sets:
SystemCallFilter=@privileged:EPERM @reboot
This will block any system call requiring super-user capabilities with
EPERM, except for attempts to reboot the system, which will immediately
terminate the process. (@reboot is included in @privileged.)
This also effectively fixes #9939, since specifying different errnos for
“the same syscall” (same pseudo syscall number) is no longer an error.
Michal Sekletar [Thu, 30 Aug 2018 08:45:11 +0000 (08:45 +0000)]
cryptsetup-generator: introduce basic keydev support
Dracut has a support for unlocking encrypted drives with keyfile stored
on the external drive. This support is included in the generated initrd
only if systemd module is not included.
When systemd is used in initrd then attachment of encrypted drives is
handled by systemd-cryptsetup tools. Our generator has support for
keyfile, however, it didn't support keyfile on the external block
device (keydev).
This commit introduces basic keydev support. Keydev can be specified per
luks.uuid on the kernel command line. Keydev is automatically mounted
during boot and we look for keyfile in the keydev
mountpoint (i.e. keyfile path is prefixed with the keydev mount point
path). After crypt device is attached we automatically unmount
where keyfile resides.
Dongsu Park [Mon, 3 Sep 2018 18:44:13 +0000 (20:44 +0200)]
importd, basic/string-util: use case-insensitive comparison for HTTP headers
According to RFC2616[1], HTTP header names are case-insensitive. So
it's totally valid to have a header starting with either `Date:` or
`date:`.
However, when systemd-importd pulls an image from an HTTP server, it
parses HTTP headers by comparing header names as-is, without any
conversion. That causes failures when some HTTP servers return headers
with different combinations of upper-/lower-cases.
An example:
https://alpha.release.flatcar-linux.net/amd64-usr/current/flatcar_developer_container.bin.bz2 returns `Etag: "pe89so9oir60"`,
while https://alpha.release.core-os.net/amd64-usr/current/coreos_developer_container.bin.bz2
returns `ETag: "f03372edea9a1e7232e282c346099857"`.
Since systemd-importd expects to see `ETag`, the etag for the Container Linux image
is correctly interpreted as a part of the hidden file name.
However, it cannot parse etag for Flatcar Linux, so the etag the Flatcar Linux image
is not appended to the hidden file name.
```
$ sudo ls -al /var/lib/machines/
-r--r--r-- 1 root root 3303014400 Aug 21 20:07 '.raw-https:\x2f\x2falpha\x2erelease\x2ecore-os\x2enet\x2famd64-usr\x2fcurrent\x2fcoreos_developer_container\x2ebin\x2ebz2.\x22f03372edea9a1e7232e282c346099857\x22.raw'
-r--r--r-- 1 root root 3303014400 Aug 17 06:15 '.raw-https:\x2f\x2falpha\x2erelease\x2eflatcar-linux\x2enet\x2famd64-usr\x2fcurrent\x2fflatcar_developer_container\x2ebin\x2ebz2.raw'
```
As a result, when the Flatcar image is removed and downloaded again,
systemd-importd is not able to determine if the file has been already
downloaded, so it always download it again. Then it fails to rename it
to an expected name, because there's already a hidden file.
To fix this issue, let's introduce a new helper function
`memory_startswith_no_case()`, which compares memory regions in a
case-insensitive way. Use this function in `curl_header_strdup()`.
See also https://github.com/kinvolk/kube-spawn/issues/304
Alan Jenkins [Wed, 29 Aug 2018 23:20:48 +0000 (00:20 +0100)]
namespace: remove redundant .has_prefix=false
The MountEntry's added for EMPTY_DIR work very similarly to the TMPFS ones.
In both cases, .has_prefix is false. In fact, .has_prefix is false in
*all* the MountEntry's we add except for the access mounts (READONLY etc).
But EMPTY_DIR stuck out by explicitly setting .has_prefix = false.
Let's remove that.
Alan Jenkins [Wed, 29 Aug 2018 23:32:54 +0000 (00:32 +0100)]
namespace: don't try to remount superblocks
We can't remount the underlying superblocks, if we are inside a user
namespace and running Linux <= 4.17. We can only change the per-mount
flags (MS_REMOUNT | MS_BIND).
This type of mount() call can only change the per-mount flags, so we
don't have to worry about passing the right string options now.
Fixes #9914 ("Since 1beab8b was merged, systemd has been failing to start
systemd-resolved inside unprivileged containers" ... "Failed to re-mount
'/run/systemd/unit-root/dev' read-only: Operation not permitted").
> It's basically my fault :-). I pointed out we could remount read-only
> without MS_BIND when reviewing the PR that added TemporaryFilesystem=,
> and poettering suggested to change PrivateDevices= at the same time.
> I think it's safe to change back, and I don't expect anyone will notice
> a difference in behaviour.
>
> It just surprised me to realize that
> `TemporaryFilesystem=/tmp:size=10M,ro,nosuid` would not apply `ro` to the
> superblock (underlying filesystem), like mount -osize=10M,ro,nosuid does.
> Maybe a comment could note the kernel version (v4.18), that lets you
> remount without MS_BIND inside a user namespace.
This makes the code longer and I guess this function is still ugly, sorry.
One obstacle to cleaning it up is the interaction between
`PrivateDevices=yes` and `ReadOnlyPaths=/dev`. I've added a test for the
existing behaviour, which I think is now the correct behaviour.
tests: also run TEST-01-BASIC in an unprivileged container (#9957)
This should make it much easier to catch regressions like
https://github.com/systemd/systemd/issues/9914 and
https://github.com/systemd/systemd/issues/8535.
Only report OOM if that was actually the error of the operation,
explicitly report the possible error that a syscall was already blocked
with a different errno and translate that into a more sensible errno
(EEXIST only makes sense in connection to the hashmap), and pass through
all other potential errors unmodified. Part of #9939.
Alan Jenkins [Mon, 27 Aug 2018 18:09:58 +0000 (19:09 +0100)]
resolve: update comment, avoid alarming wrongness
`systemd-resolved.service` runs as `User=systemd-resolved`, and uses certain
Capabilit{y,ies} magic. By my understanding, this means it is started with a
number of "privileges". Indeed, `capabilities(7)` explains
> Linux divides the privileges traditionally
> associated with superuser into distinct units, known as capabilities,
> which can be independently enabled and disabled."
This situation appears to contradict our current code comment which said
> If we are not running as root we assume all privileges are already dropped.
This appears to be a confusion in the comment only. The rest of the code
tells a much clearer story. (Don't ask me if the story is correct.
`capabilities(7)` scares me). Let's tweak the comment to make it consistent
and avoid worrying readers about this.
Samuel Morris [Tue, 28 Aug 2018 14:40:51 +0000 (10:40 -0400)]
systemctl: if no logind, don't try to schedule shutdown
If logind is not supported, don't try to schedule a shutdown,
immediately poweroff. This is the behavior indicated by the current
message given to the user, but the command is returning an error. I
believe this was broken on this commit: 7f96539d45028650f2ba9452095473a9c455d84b