This commit adds the possibility to leave /sys, and /proc/sys read-write.
It introduces a new (undocumented) env var SYSTEMD_NSPAWN_API_VFS_WRITABLE
to enable this feature.
If set to "yes", /sys, and /proc/sys will be read-write.
If set to "no", /sys, and /proc/sys will be read-only.
If set to "network" /proc/sys/net will be read-write. This is useful in
use-cases, where systemd-nspawn is used in an external network
namespace.
This adds the possibility to start privileged containers which need more
control over settings in the /proc, and /sys filesystem.
This is also a follow-up on the discussion from
https://github.com/systemd/systemd/pull/4018#r76971862 where an
introduction of a simple env var to enable R/W support for those
directories was already discussed.
==30496== Conditional jump or move depends on uninitialised value(s)
==30496== at 0x489F654: memcmp (vg_replace_strmem.c:1091)
==30496== by 0x49BF203: getenv_for_pid (process-util.c:678)
==30496== by 0x4993ACB: detect_container (virt.c:442)
==30496== by 0x182DFF: test_get_process_comm (test-process-util.c:98)
==30496== by 0x185847: main (test-process-util.c:368)
==30496==
For some reasons units remaining in the same process group as PID 1
(same_pgrp=true) fail to acquire the console even if it's not taken by anyone.
So always accept for units with same_pgrp set for now.
Previously it was "[Yes, Fail, Skip]" which is pretty misleading because it
suggests that the whole word needs to be entered instead of a single char.
Also this won't fit well when we'll extend the number of choices.
This patch addresses this by changing the choice hint with "[y, f, s – h for help]"
so it's now clear that a single letter has to be entered.
It also introduces a new choice 'h' which describes all possible choices since
a single letter can be not descriptive enough for new users.
It also allow to stick with the same hint string regardless of how
many choices we will support.
When "confirmation_spawn=1", the confirmation question can look like:
Execute /usr/bin/kmod static-nodes --format=tmpfiles --output=/run/tmpfiles.d/kmod.conf? [Yes, No, Skip]
which is pretty verbose and might not fit in the console width size (which is
usually 80 chars) and thus question will be splitted into 2 consecutive lines.
However since the question is now refreshed every 2 secs, the reprinted
question will overwrite the second line of the previous one...
To prevent this, this patch makes sure that the command line won't be longer
than 60 chars by ellipsizing it if the command is longer:
Execute /usr/bin/kmod static-nodes --format=tmpfiles --output=/ru…nf? [Yes, No, View, Skip]
A following patch will introduce a new choice that will allow the user to get
details on the command to be executed so it will still be possible to see the
full command line.
ask_char() now reprints the question every 2sec automatically.
It prefixes its output with '\r' to to bring the cursor to the
beginning of the terminal line, and then print the message, redoing it
every 2sec.
As long as nothing interferes with out output this logic will have no
visible effect as we constantly overprint the visible text with the
exact same text.
However, if something is dumped in the middle, then our question won't
get lost, as we'll ask soon again.
This is useful if the question is asked to a terminal that is also
used to dump some other status messages/logs. For example when
confirmation messages are enabled during the boot
(systemd.confirm_spawn=1), the question can easily be lost if the
kernel logs are also enabled and both use the same console.
Idea suggested by Lennart Poettering.
Before this patch we had:
- "no" which gives "failing execution" but the command is actually assumed as
succeed.
- "skip" which gives "skipping", but the command is assumed to have failed,
which ends up with "Failed to start ..." on the console.
Now we have:
- "fail" which gives "failing execution" and the command is indeed assumed as
failed.
- "skip" which gives "skipping execution" and the command is assumed as
succeed.
Now the reponses are handled by ask_for_confirmation() as well as the report of
any errors occuring during the process of retrieving the confirmation response.
One benefit of this is that there's no need to open/close the console one more
time when reporting error/status messages.
The caller now just needs to care about the return values whose meanings are:
- don't execute and pretend that the command failed
- don't execute and pretend that the command succeeed
- positive answer, execute the command
Also some slight code reorganization and introduce write_confirm_error() and
write_confirm_error_fd(). write_confim_message becomes unneeded.
It's rather hard to parse the confirmation messages (enabled with
systemd.confirm_spawn=true) amongst the status messages and the kernel
ones (if enabled).
This patch gives the possibility to the user to redirect the confirmation
message to a different virtual console, either by giving its name or its path,
so those messages are separated from the other ones and easier to read.
When booting with systemd.confirm_spawn=true, the eye of cylon
animation kicks in pretty quickly so user doesn't have any chance to
answer the questions which services to start before the confirmation
message is screwed by the cylon.
This basically breaks the confirm_spawn functionality completely.
This patch prevents the cylon animation to kick in when
confirmation_spawn=yes.
Fixes: #2194
Let's align all our BindMount tables, let's use the same column widths in all
of them, and let's make them not any wider than necessary.
This only changes whitespace, not contents of any of the tables.
This changes a couple of things in the namespace handling:
It merges the BindMount and TargetMount structures. They are mostly the same,
hence let's just use the same structue, and rely on C's implicit zero
initialization of partially initialized structures for the unneeded fields.
This reworks memory management of each entry a bit. It now contains one "const"
and one "malloc" path. We use the former whenever we can, but use the latter
when we have to, which is the case when we have to chase symlinks or prefix a
root directory. This means in the common case we don't actually need to
allocate any dynamic memory. To make this easy to use we add an accessor
function bind_mount_path() which retrieves the right path string from a
BindMount structure.
While we are at it, also permit "+" as prefix for dirs configured with
ReadOnlyPaths= and friends: if specified the root directory of the unit is
implicited prefixed.
This also drops set_bind_mount() and uses C99 structure initialization instead,
which I think is more readable and clarifies what is being done.
This drops append_protect_kernel_tunables() and
append_protect_kernel_modules() as append_static_mounts() is now simple enough
to be called directly.
Prefixing with the root dir is now done in an explicit step in
prefix_where_needed(). It will prepend the root directory on each entry that
doesn't have it prefixed yet. The latter is determined depending on an extra
bit in the BindMount structure.
When waiting for the terminal to be release in acquire_terminal(), we
were monitoring the terminal fd instead of the inotify descriptor.
Therefore any write accesses would wake up the waiting process instead
of being wake up when the tty is closed only.
Automatically GC device jobs when there's no need to keep them in the job queue anymore.
Implement systemctl list-jobs --before/--after.
Allow systemd-run -p After/Before/Wants/Requires= ...
(before)$ systemctl list-jobs --before --after
JOB UNIT TYPE STATE
8769 foobar.device start running
A job waits for this job: 8669 (run-rb6da596d0cfa4e36b7c594cd973e795a.service/start)
8669 run-rb6da596d0cfa4e36b7c594cd973e795a.service start waiting
This job waits for a job: 8769 (foobar.device/start)
2 jobs listed.
(after)$ systemctl list-jobs --before --after
JOB UNIT TYPE STATE
8769 foobar.device start running
waiting for job 8669 (run-rb6da596d0cfa4e36b7c594cd973e795a.service/start)
8669 run-rb6da596d0cfa4e36b7c594cd973e795a.service start waiting
blocking job 8769 (foobar.device/start)
2 jobs listed.
Sometimes it is useful for debugging purposes to force systemctl to connect to
PID 1 via the bus instead of direct connection, even if the direct connection
is possible.
In contrast to all other unit types device units when queued just track
external state, they cannot effect state changes on their own. Hence unless a
client or other job waits for them there's no reason to keep them in the job
queue. This adds a concept of GC'ing jobs of this type as soon as no client or
other job waits for them anymore.
To ensure this works correctly we need to track which clients actually
reference a job (i.e. which ones enqueued it). Unfortunately that's pretty
nasty to do for direct connections, as sd_bus_track doesn't work for
them. For now, work around this, by simply remembering in a boolean that a job
was requested by a direct connection, and reset it when we notice the direct
connection is gone. This means the GC logic works fine, except that jobs are
not immediately removed when direct connections disconnect.
In the longer term, a rework of the bus logic should fix this properly. For now
this should be good enough, as GC works for fine all cases except this one, and
thus is a clear improvement over the previous behaviour.
Fixes: #1921
Let's make semantics of this field more similar to the same functionality in
the Unit object, in particular as we add new functionality to it later on.
The RestrictNamespaces= takes yes, no or a list of namespaces types,
therefor config_parse_restrict_namespaces() is a bit complex and it
operates on the ExecContext, fix this by passing the offset of
ExecContext directly otherwise restricting namespaces won't work.
The no_new_privileged_set variable is not used any more since commit
9b232d3241 that fixed another thing. So remove it. Also no
need to check if we are under user manager, remove that part too.
