Let's tighten rules on namespace operations: let's always ask PK for
permission before doing anything.
Note that if polkit is absent we'll still allow things, and the default
PK policy will also still allow things, but there's now a clear way how
people can not allow things if they want, by modifying the PK policy.
Let's tighten the screws a bit on the network interfaces we delegate,
and explicitly destroy them, just like we destroy delegated cgroups.
Ideally, this should happen automatically because the userns goes away
that pins the veth, or because the client holding an fd for a tap device
goes away as the userns goes away. But you never know who keeps a
reference, hence let's explicitly destroy this too.
This is a simple helper for creating a userns that just maps the
callers user to UID 0 in the namespace. This can be acquired unpriv,
which makes it useful for various purposes, for example for the logic in
is_idmapping_supported(), hence port it over.
(is_idmapping_supported() used a different mapping before, with the
nobody users, but there's no real reason for that, and we'll use
userns_acquire_self_root() elsewhere soon, where the root mapping is
important).
Unprivileged namespaces are only allowed if the "setgroups" file is set
to "deny" for processes. And we need to write it before writing the
gidmap. Hence add a parameter for that.
Then, also patch all current users to actually enable this. The usecase
generally don't need it (because they don't care about unprivileged
userns), but it doesn't hurt to enable the concept anyway in all current
users (none of them actually runs complex userspace in them, but they
mostly use userns_acquire() for idmapped mounts and similar).
Let's anyway make this option explicit in the function call, to indicate
that the concept exists and is applied.
I recently noticed that our serial/VM terminals did not get fedora's
color shell prompt, nor got color support in "ls".
I spend a bit of time investigating and it's all a bit of a mess. If we
don't have any idea what kind of terminal we are talking to via serial
or hypervisor console then we so far just set TERM=vt220 as a reasonable
fallback: vt220 is quite universally defined in terminfo/termcap, and it
supports pageup/pagedown (unlike vt100).
However, real vt220 DEC terminals did not support color, and hence
termcap/terminfo says "no color, sorry". Which sucks, but actually
neither coreutils' "ls" (via `dircolors`) nor fedora's color shell
prompt actually care for termcap/terminfo. So why don't we get color?
In the coreutils case: it has it's own mini-database of terminals. A
very skewed one, where TERM=vt100 enables colors (and DEC vt100
definitely never ever had color support!), but vt220 does not. However,
what it actually does is check $COLORTERM. If that's set then it would
enable color.
In the fedora color prmpt case: it tries to derive color support by
looking for the word "color" in $TERM. Horrible hack if you ask me...
In order to make things better I did a bunch of things:
1. I think the idea of actually having a fully correct and up-to-date
termcap/terminfo database is kinda illusionary these days. But
apparently regarding color support $COLORTERM kinda took it place.
coreutils cares, and systemd itself cares too. To some point at least:
we consume it to determine color support, but we never propagate it in
nspawn, run0 and so on. So this PR fixes that.
2. Also, we are kinda stuck with vt220 I guess as default fallback for
serial terminals. But let's tweak it, and set $COLORTERM=truecolor as
default too. this means we default to a vt220 terminal, but with color.
Which is an ahistorical thing to do, but I think it's the best way out.
3. I also filed a bug against util-linux asking them to treat $COLORTERM
like $TERM, and let it propagate from getty into login shell:
https://github.com/util-linux/util-linux/issues/3463 – With that we
should get color support in ls by default now.
4. I also asked coreutils to treat vt220 the same as they already treat
vt100 and simply do color, even if though that's ahistorical:
https://github.com/coreutils/coreutils/issues/96
5. I then asked the fedora color prompt package to check $COLORTERM:
https://bugzilla.redhat.com/show_bug.cgi?id=2352650
6. I also asked the fedora ssh package to propagate $COLORTERM to remote
hosts by default, like they already cover $TERM. terminal emulators set
both these days generally, hence this would make sense.
https://bugzilla.redhat.com/show_bug.cgi?id=2352653
7. while at it, I figured it makes sense to not only propagate/consume
$COLORTERM at the same time as $TERM, but also consider $NO_COLOR. In
contrast to $COLORTERM for which no spec seems to exist, that one
actually does have a spec: https://no-color.org/
It might make sense for those interested in other distros than Fedora to
maybe ask for similar changes for their ssh and color shell prompt
packages (if they have something coresponding).
To support C23, this introduces UTF8() macro to define UTF-8 literals,
as C23 changed char8_t from char to unsigned char.
This also makes pointer signedness warning critical, and updates C
standards table for tests.
When we pass information about our calling terminal on to some service
or command we invoke, propagate $COLORTERM + $NO_COLOR in addition to
$TERM, in order to always consider the triplet of the three env vars the
real deal.
I think we should work towards always picking up the triplet of $TERM +
$COLORTERM + $NO_COLOR where we so far picked up $TERM only. I think
it's safe to say that at this time, $TERM is not enough anymore to
clearly communicate terminal feature support. Hence, teach PID 1 to pick
$COLORTERM + $NO_COLOR wherever we pick up $TERM.
When we configure a serial or VM terminal and have no $TERM
configuration, then we default to vt220 as a fallback. This is a pretty
safe bet, since the termcap/terminfo definitions for vt220 are
relatively widely available (much like vt100), and (in contrast to
vt100) it supports pageup/pagedown keys. vt220 is a terminal without
color support however, but we do want color support, because in 2025
there's really no terminal emulator without color in this world.
The $COLORTERM env var is used my many emulators and tools to
communicate that ANSI color support is available, despite what $TERM
says. Hence, let's tweak systemd's logic to also set $COLORTERM in case
we set the vt220 $TERM fallback.
This means we define an ahistoric frankenterminal: a vt220 (that
historically definitely didn't have color) that is explicitly configured
to have color.
One effect of this is that coreutils' dircolors command will start to
output color sequences in systemd's serial or VM terminals. (Since it
actually honours $COLORTERM).
Also note that systemd itself checks $COLORTERM since a long time, hence
it makes sense for us to also set it.
Note that this unfortunately doesn't have the desired effect of
propagating $COLORTERM into any getty shell sessions yet. That's because
util-linux' login package currently fiters $COLORTERM (but lets $TERM
though). I filed a bug about that here:
https://github.com/util-linux/util-linux/issues/3463
If btrfs builtin command is called, then check if the specified device
node is owned by the device.
This also allows the command is called specifying any device node.
This is useful when the previous invocation is unexpectedly killed.
Otherwise, if systemd-nspawn is killed forcibly, then unix-export
directory is not cleared and unmounted, and the subsequent invocation
will fail. E.g.
```
[ 18.895515] TEST-13-NSPAWN.sh[645]: + machinectl start long-running
[ 18.945703] systemd-nspawn[1387]: Mount point '/run/systemd/nspawn/unix-export/long-running' exists already, refusing.
[ 18.949236] systemd[1]: systemd-nspawn@long-running.service: Failed with result 'exit-code'.
[ 18.949743] systemd[1]: Failed to start systemd-nspawn@long-running.service.
```
Followup to c0cc01de8a
The targets that create indicies have
`install : want_html and have_lxml` but some other
code like the `install_symlink` was not gated by
accident.
We ican put the whole loop behind have_lxml as its
required for all the indicies.
lxc tries to mount /sys/fs/cgroup/ following host hierarchy by default,
which is problematic for us since we want to unconditionally use
cgroup v2 in cgns. Disable it hence and let pid1 figure it out.
This is useful when the previous invocation is unexpectedly killed.
Otherwise, if systemd-nspawn is killed forcibly, then unix-export
directory is not cleared and unmounted, and the subsequent invocation
will fail. E.g.
===
[ 18.895515] TEST-13-NSPAWN.sh[645]: + machinectl start long-running
[ 18.945703] systemd-nspawn[1387]: Mount point '/run/systemd/nspawn/unix-export/long-running' exists already, refusing.
[ 18.949236] systemd[1]: systemd-nspawn@long-running.service: Failed with result 'exit-code'.
[ 18.949743] systemd[1]: Failed to start systemd-nspawn@long-running.service.
===
C23 changed char8_t from char to unsigned char, hence assigning a u8 literal
to const char* emits pointer sign warning, e.g.
========
../src/shared/qrcode-util.c: In function ‘print_border’:
../src/shared/qrcode-util.c:16:34: warning: pointer targets in passing argument 1 of ‘fputs’ differ in signedness [-Wpointer-sign]
16 | #define UNICODE_FULL_BLOCK u8"█"
| ^~~~~
| |
| const unsigned char *
../src/shared/qrcode-util.c:65:39: note: in expansion of macro ‘UNICODE_FULL_BLOCK’
65 | fputs(UNICODE_FULL_BLOCK, output);
| ^~~~~~~~~~~~~~~~~~
========
This introduces UTF8() macro, which define u8 literal and casts to consth char*,
then rewrites all u8 literal definitions with the macro.
With this change, we can build systemd with C23.
The log line looked like this:
bootctl[1457]: ! Mount point '/efi' which backs the random seed file is world accessible, which is a security hole! !
which doesn't look nice.
Also upgrade the message to error. This is something to fix.
