When --ephemeral is used, a random 16 characters suffix is added to the image
name, so matching on .nspawn files based on the image name no longer works.
Fixes https://github.com/systemd/systemd/issues/13297
No actual code changes, just splitting out of some dev_t handling
related calls from stat-util.[ch], they are quite a number already, and
deserve their own module now I think.
Also, try to settle on the name "devnum" as the name for the concept,
instead of "devno" or "dev" or "devid". "devnum" is the name exported in
udev APIs, hence probably best to stick to that. (this just renames a
few symbols to "devum", local variables are left untouched, to make the
patch not too invasive)
No actual code changes.
So here's something we should always keep in mind:
systemd-udevd actually does *two* things with BSD file locks on block
devices:
1. While it probes a device it takes a LOCK_SH lock. Thus everyone else
taking a LOCK_EX lock will temporarily block udev from probing
devices, which is good when making changes to it.
2. Whenever a device is closed after write (detected via inotify), udevd
will issue BLKRRPART (requesting the kernel to reread the partition
table). It does this while holding a LOCK_EX lock on the block
device. Thus anyone else taking LOCK_SH or LOCK_EX will temporarily
block udevd from issuing that ioctl. And that's quite relevant, since
the kernel will temporarily flush out all partitions while re-reading
the partition table and then create them anew. Thus it is smart to
take LOCK_SH when dissecting a block device to ensure that no
BLKRRPART is issued in the background, until we mounted the devices.
We would use a relative path, looking for globs like
'lib/systemd/libsystemd-shared-*.so' under the build directory, and never find
anything.
The test was supposed to find library in the current installation. But we
cannot assume that the right library is installed, so the test only printed the
result for manual inspection. Thus nobody noticed when it broke. I think it
broke in c6134d3e2f, path-util: get rid of prefix_root().
But that commit doesn't compile because of changes in meson, so this is just
a guess.
Before:
/* test_systemd_installation_has_version */
Current installation has systemd >= 0: no
Current installation has systemd >= 231: no
Current installation has systemd >= 249: no
Current installation has systemd >= 999: no
With the fix:
$ build/test-nspawn-util
/* test_systemd_installation_has_version */
Found libsystemd shared at "/lib/systemd/libsystemd-shared-245.so.so", version 245 (OK).
Current installation has systemd >= 0: yes
Found libsystemd shared at "/lib/systemd/libsystemd-shared-245.so.so", version 245 (OK).
Current installation has systemd >= 231: yes
Found libsystemd shared at "/lib/systemd/libsystemd-shared-245.so.so", version 245 (too old).
Found libsystemd shared at "/lib/systemd/libsystemd-shared-251.so.so", version 251 (OK).
Current installation has systemd >= 251: yes
Found libsystemd shared at "/lib/systemd/libsystemd-shared-245.so.so", version 245 (too old).
Found libsystemd shared at "/lib/systemd/libsystemd-shared-251.so.so", version 251 (too old).
Found libsystemd shared at "/lib/systemd/libsystemd-shared-250.so.so", version 250 (too old).
Found libsystemd shared at "/usr/lib/systemd/libsystemd-shared-245.so.so", version 245 (too old).
Found libsystemd shared at "/usr/lib/systemd/libsystemd-shared-251.so.so", version 251 (too old).
Found libsystemd shared at "/usr/lib/systemd/libsystemd-shared-250.so.so", version 250 (too old).
Current installation has systemd >= 999: no
$ build/test-nspawn-util /var/lib/machines/rawhide
/* test_systemd_installation_has_version */
/* test_systemd_installation_has_version */
Found libsystemd shared at "/var/lib/machines/rawhide/lib/systemd/libsystemd-shared-251-rc1-1.fc37.so.so", version 251 (OK).
/var/lib/machines/rawhide has systemd >= 0: yes
Found libsystemd shared at "/var/lib/machines/rawhide/lib/systemd/libsystemd-shared-251-rc1-1.fc37.so.so", version 251 (OK).
/var/lib/machines/rawhide has systemd >= 231: yes
Found libsystemd shared at "/var/lib/machines/rawhide/lib/systemd/libsystemd-shared-251-rc1-1.fc37.so.so", version 251 (OK).
/var/lib/machines/rawhide has systemd >= 251: yes
Found libsystemd shared at "/var/lib/machines/rawhide/lib/systemd/libsystemd-shared-251-rc1-1.fc37.so.so", version 251 (too old).
Found libsystemd shared at "/var/lib/machines/rawhide/usr/lib/systemd/libsystemd-shared-251-rc1-1.fc37.so.so", version 251 (too old).
/var/lib/machines/rawhide has systemd >= 999: no
While at it, NULSTR_FOREACH → FOREACH_STRING.
See a2b0cd3f5a. When -Dshared-lib-tag is used,
libsystemd-shared.so and libsystemd-core.so get a suffix which breaks the
parsing done by systemd_installation_has_version(). We can assume that the
tag will be something like "251-rc1-1.fc37" that is currently used in Fedora.
(Anything that does *not* start with the version would be completely crazy.)
By switching to strverscmp_improved() we simplify the code and fix comparisons
with such versions.
$ build/test-nspawn-util /var/lib/machines/rawhide
...
Found libsystemd shared at "/var/lib/machines/rawhide/lib/systemd/libsystemd-shared-251-rc1-1.fc37.so.so", version 251-rc1-1.fc37 (OK).
/var/lib/machines/rawhide has systemd >= 251: yes
...
I noticed this when I started a systemd-nspawn container with Redora rawhide
and got the message "Not running with unified cgroup hierarchy, LSM BPF is not
supported". I thought the message is in error, but it was actually correct:
nspawn was misdetecting that the container does not sport new-enough systemd
to support cgroups-v2.
This function implements a heuristic that is only used by nspawn. It doesn't
belong in basic. I opted for a new file "nspawn-utils.c", because it seems
likely that we'll need some other new utilities like that in the future.
No functional change.
Defaults to /bin/bash, no changes in the default configuration
The fallback shell for non-root users is as-specified,
and the interactive shell for nspawn sessions is started as
exec(default-user-shell, "-" + basename(default-user-shell), ...)
before falling through to bash and sh
Same idea as 03677889f0.
No functional change intended. The type of the iterator is generally changed to
be 'const char*' instead of 'char*'. Despite the type commonly used, modifying
the string was not allowed.
I adjusted the naming of some short variables for clarity and reduced the scope
of some variable declarations in code that was being touched anyway.
When using user namespaces in conjunction with uidmapped mounts, nspawn
so far set up two uidmappings:
1. One that is used for the uidmapped mount and that maps the UID range
0…65535 on the backing fs to some high UID range X…X+65535 on the
uidmapped fs. (Let's call this mapping the "mount mapping")
2. One that is used for the userns namespace the container payload
processes run in, that maps X…X+65535 back to 0…65535. (Let's call
this one the "process mapping").
These mappings hence are pretty much identical, one just moves things up
and one back down. (Reminder: we do all this so that the processes can
run under high UIDs while running off file systems that require no
recursive chown()ing, i.e. we want processes with high UID range but
files with low UID range.)
This creates one problem, i.e. issue #20989: if nspawn (which runs as
host root, i.e. host UID 0) wants to add inodes to the uidmapped mount
it can't do that, since host UID 0 is not defined in the mount mapping
(only the X…X+65536 range is, after all, and X > 0), and processes whose
UID is not mapped in a uidmapped fs cannot create inodes in it since
those would be owned by an unmapped UID, which then triggers
the famous EOVERFLOW error.
Let's fix this, by explicitly including an entry for the host UID 0 in
the mount mapping. Specifically, we'll extend the mount mapping to map
UID 2147483646 (which is INT32_MAX-1, see code for an explanation why I
picked this one) of the backing fs to UID 0 on the uidmapped fs. This
way nspawn can creates inode on the uidmapped as it likes (which will
then actually be owned by UID 2147483646 on the backing fs), and as it
always did. Note that we do *not* create a similar entry in the process
mapping. Thus any files created by nspawn that way (and not chown()ed to
something better) will appear as unmapped (i.e. as overflowuid/"nobody")
in the container payload. And that's good. Of course, the latter is
mostly theoretic, as nspawn should generally chown() the inodes it
creates to UID ranges that actually make sense for the container (and we
generally already do this correctly), but it#s good to know that we are
safe here, given we might accidentally forget to chown() some inodes we
create.
Net effect: the two mappings will not be identical anymore. The mount
mapping has one entry more, and the only reason it exists is so that
nspawn can access the uidmapped fs reasonably independently from any
process mapping.
Fixes: #20989
This mirrors a similar check in Linux kernel 5.16
(9dcc38e2813e0cd3b195940c98b181ce6ede8f20) that raised the
RLIMIT_MEMLOCK to 8M.
This change does two things: raise the default limit for nspawn
containers (where we try to mimic closely what the kernel does), and
bump it when running on old kernels which still have the lower setting.
Fixes: #16300
See: https://lwn.net/Articles/876288/
The approach to use '''…'''.split() instead of a list of strings was initially
used when converting from automake because it allowed identical blocks of lines
to be used for both, making the conversion easier.
But over the years we have been using normal lists more and more, especially
when there were just a few filenames listed. This converts the rest.
No functional change.
We expose various other forms of UUID helpers already, i.e.
SD_ID128_UUID_FORMAT_STR and SD_ID128_MAKE_UUID_STR(), and we parse
UUIDs, hence add a high-level helper for formatting UUIDs too.
This doesn't add any new code, it just moves some helpers
id128-util.[ch] → sd-id128.[ch], to make them public.
The meson default for static_library() are:
build_by_default=true, install=false. We never interact with the
static libraries, and we only care about them as a stepping-stone towards
the installable executables or libraries. Thus let's only build them if
they are a dependency of something else we are building.
While at it, let's drop install:false, since this appears to be the default.
This change would have fixed the issue with lib_import_common failing
to build too: we wouldn't attempt to build it.
In practice this changes very little, because we generally only declare static
libraries where there's something in the default target that will make use of
them. But it seems to be a better pattern to set build_by_default to false.
The variable is not useful outside of the loop (it'll always be null
after the loop is finished), so we can declare it inline in the loop.
This saves one variable declaration and reduces the chances that somebody
tries to use the variable outside of the loop.
For consistency, 'de' is used everywhere for the var name.
This macro is like JSON_BUILD_STRING() but uses our json library's
ability to use literal strings directly as JsonVariant objects.
The changes all our codebase to use this new macro whenever we build
JSON objects from literal strings.
(I tried to make this automatic, i.e. to detect in JSON_BUILD_STRING()
whether something is a literal string nicely and thus do this stuff
automatically, but I couldn't find a way.)
This should reduce memory usage of our JSON code a bit. Constant strings
we use very often will now be shared and mapped directly from the ELF
image.
We were already asserting that the intmax_t and uintmax_t types
are the same as int64_t and uint64_t. Pretty much everywhere in
the code base we use the latter types. In principle intmax_t could
be something different on some new architecture, and then the code would
fail to compile or behave differently. We actually do not want the code
to behave differently on those architectures, because that'd break
interoperability. So let's just use int64_t/uint64_t since that's what
we indend to use.
Previously the mkdir_label() family of calls was implemented in
src/shared/mkdir-label.c but its functions partly declared ins
src/shared/label.h and partly in src/basic/mkdir.h (!!). That's weird
(and wrong).
Let's clean this up, and add a proper mkdir-label.h matching the .c
file.
Our goal here (as in the previous commits) is to ensure that a settings
file loaded in --settings=override mode is truly a NOP. Previously this
was not the case as we'd drop CAP_NET_ADMIN from the caps if the
settings file didn't enable networking.
With this change we'll drop it only if explicitly turned off in the
settings file, and otherwise let the built-in defaults and cmdline
params reign supreme as documented.
Fixes: #20055
Let's only pick this up from the settings if actually set.
As in the previous commit this makes sure that an empty settings file in
--settings=override mode is really a NOP.
Let's turn these three fields into tristates, so that we can distinguish
whether they are not configured at all from explicitly turned off.
Let#s then use this to ensure that we only copy the settings fields into
our execution environment if they are actually configured.
We already do this for some of the boolean settings, this adds it for
the missing ones.
The goal here is to ensure that an empty settings file used in
--settings=override mode (i.e. the default mode used in the
systemd-nspawn@.service unit) is truly a NOP.
The new helper returns whether the settings file had *any* networking
setting configured at all. We already have a similar helper
settings_private_network() which returns a similar result. The
difference is that the new helper will return true when the private
network was explicitly turned off, while the old one will only return
true if configured and enabled.
We'll reuse the helper a 2nd time later on, but even without it it makes
things a bit more readable.
rearrange_stdio() invalidates specified fds even on failure, which means
we should always invalidate the fds we pass in no matter what. Let's
make this explicit by using TAKE_FD() for that everywhere.
Note that in many places we such invalidation doesnt get us much
behaviour-wise, since we don't use the variables anymore later. But
TAKE_FD() in a way is also documentation, it encodes explicitly that the
fds are invalidated here, so I think it's a good thing to always make
this explicit here.
Luca Boccassi
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
наб
Yu Watanabe
Michael Biebl
Jan Janssen
Evgeny Vereshchagin
Luca Boccassi