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.
Most sd_notify() calls are like log_info() — the result is only informative
and if they fail, it's best ignore this. But if a call with READY=1 fails,
the unit may enter a failed state, so we should warn about this. Similarly
for FSTOREREMOVE=1: the manager may be left with a stale fd, at least wasting
resources.
This makes sure that a switch like --bind=:/foo does the right thing if
user namespacing is one: the backing dir should be owned by the
container's root UID not the host's. Thus, whenever the source path is
left empty and we automatically generate a source dir as temporary
directory, ensure it's owned by the right UID.
Fixes: #20869
We try to pass containers roughly the same rlimits as the host gets from
the kernel. However, this means we'd set the RLIMIT_NOFILE to 4K. Which
is quite limiting though, and is something we actually departed from in
PID1: since 52d6207578 we raise the limit
substantially for all userspace.
Given that nspawn is quite often invoked without proper PID1, let's raise the
limits for container payloads the same way as we do from the real PID1
to its service payloads.
This is supposed to be used by package/image builders such as mkosi to
speed up building, since it allows us to suppress sync() inside a
container.
This does what Debian's eatmydata tool does, but for a container, and
via seccomp (instead of LD_PRELOAD).
Let's define two helpers strdupa_safe() + strndupa_safe() which do the
same as their non-safe counterparts, except that they abort if called
with allocations larger than ALLOCA_MAX.
This should ensure that all our alloca() based allocations are subject
to this limit.
afaics glibc offers three alloca() based APIs: alloca() itself,
strndupa() + strdupa(). With this we have now replacements for all of
them, that take the limit into account.
LLVM 13 introduced `-Wunused-but-set-variable` diagnostic flag, which
trips over some intentionally set-but-not-used variables or variables
attached to cleanup handlers with side effects (`_cleanup_umask_`,
`_cleanup_(notify_on_cleanup)`, `_cleanup_(restore_sigsetp)`, etc.):
```
../src/basic/process-util.c:1257:46: error: variable 'saved_ssp' set but not used [-Werror,-Wunused-but-set-variable]
_cleanup_(restore_sigsetp) sigset_t *saved_ssp = NULL;
^
1 error generated.
```
Let's make the booleans indicating verity state a bit more descriptive.
Let's rename:
can_verity → has_verity: because that's really what this about
whether verity data is included in the image. Whether we actually
can use it is a different story.
verity → verity_ready: this one should tell us if we have everything
need to actually set it up, hence explicitly say "ready to use" in
the name.
No change in behaviour. Just a bit of renaming.
It expects a generic "struct sockaddr", not a "struct sockaddr_un".
Pass the right member of the union.
Not sure why gcc/llvm never complained about this...
systemd-socket-activate has supported such a mode since
5e65c93a43. '--setenv=FOO=$FOO' is a fairly
common use in scripts, and it's nicer to do this automatically without worrying
about quoting and whatnot.
https://github.com/systemd/mkosi/pull/765 added the same to 'mkosi --environment='.
In general we almost never hit those asserts in production code, so users see
them very rarely, if ever. But either way, we just need something that users
can pass to the developers.
We have quite a few of those asserts, and some have fairly nice messages, but
many are like "WTF?" or "???" or "unexpected something". The error that is
printed includes the file location, and function name. In almost all functions
there's at most one assert, so the function name alone is enough to identify
the failure for a developer. So we don't get much extra from the message, and
we might just as well drop them.
Dropping them makes our code a tiny bit smaller, and most importantly, improves
development experience by making it easy to insert such an assert in the code
without thinking how to phrase the argument.
DISKSEQ is a reliable way to find out if we missed a uevent or not, as
it's monotonically increasing. If we parse an event with a smaller or
no sequence number, we know we need to wait longer. If we parse an
event with a greater sequence number, we know we missed it and the
device was reused.
Fixes a bug introduced by cfea7618f2.
Before this commit:
mode=1777,size=10%,nr_inodes=400k,uid=496107520,gid=496107520,context=,sys.id:sys.role:systemd.nspawn.container.fs:s0,
After this commit:
mode=1777,size=10%,nr_inodes=400k,uid=496107520,gid=496107520,context=sys.id:sys.role:systemd.nspawn.container.fs:s0
Fixes#19976.
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Luca Boccassi
Andreas Valder
Yu Watanabe
Dimitri Papadopoulos
Frantisek Sumsal