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.
We want user records to be extensible, hence we shouldn't complain about
fields we can't parse. In particular we want them to be extensible for
our own future extensions.
Some code already turned the permissive flag when parsing the JSON data,
but most did not. Fix that. A few select cases remain where the bit is
not set: where we just gnerated the JSON data ourselves, and thus can be
reasonably sure that if we can't parse it it's our immediate programming
error and not just us processing a user record from some other tool or a
newer version of ourselves.
This new option does three things for a host user specified via
--bind-user=:
1. Bind mount the home directory from the host directory into
/run/host/home/<username>
2. Install an additional user namepace UID/GID mapping mapping the host
UID/GID of the host user to an unused one from the container in the range
60514…60577.
3. Synthesize a user/group record for the user/group under the same name
as on the host, with minimized information, and the UID/GID set to
the mapped UID/GID. This data is written to /run/host/userdb/ where
nss-system will pick it up.
This should make sharing users and home directories from host into the
container pretty seamless, under some conditions:
1. User namespacing must be used.
2. The host UID/GID of the user/group cannot be in the range assigned to
the container (kernel already refuses this, as this would mean two
host UIDs/GIDs might end up being mapped to the same continer
UID/GID.
3. There's a free UID/GID in the aforementioned range in the container,
and the name of the user/group is not used in the container.
4. Container payload is new enough to include an nss-systemd version
that picks up records from /run/host/userdb/
