The latter is identical to the former, but becomes a NOP if
/var/log/journal is on the same mount as /, and thus during shutdown
unmounting /var is not necessary and hence we can keep logging until the
very end.
This adds a minimal Varlink (https://varlink.org/) implementation to our
tree. Given that we already have a JSON logic it's an easy thing to add.
Why bother?
We currently have major problems with IPC before dbus-daemon is up, and
in all components that dbus-daemon itself makes use of (such as various
NSS modules to resolve users as well as the journal which dbus-daemon
logs to). Because of that we so far ended up creating various (usually
crappy) work-arounds either coming up with secondary IPC systems or
sharing data statelessly in /run or similar. Let's clean this up, and
instead use a clean, well-defined, broker-less IPC for cases like that.
This is a minimal implementation of Varlink, i.e. the most basic logic
only. Stuff that's missing is left out on purpose: there's no
introspection/validation and there's no name service. It might make
sense to add that later, but for now let's only do the minimum buy-in we
can get away with. In particular as I'd assume that at least initially
we only use this IPC for our internal communication avoiding
introspection and the name service should be fine.
Specifically, I'd expect that we add IPC interfaces to the following
concepts with this scheme:
1. nss-resolve (so that hostname lookups with resolved work before
resolved is up)
2. journald (so that IPC calls to journald don't have to go through
dbus-daemon thus creating a cyclic dependency between journald and
dbus-daemon)
3. nss-systemd (so that dynamic user lookups via PID 1 work sanely even
inside of dbus-daemon, because otherwise we'd want to use dbus to run
dbus which causes deadlocks)
4. networkd (to make sure one can talk to it in the initrd already,
long before dbus is around)
And there might be other cases similar to this.
Certain distributions (e.g. Arch Linux) require booting with initrd, as
they lack support for commonly used filesystems in the kernel (i.e. the
support is compiled in as modules)
The `mount` utility has an unexpected behavior when run with libasan,
causing false-positives during the integration testing.
For example, on Arch Linux with LD_PRELOAD pointing to libasan:
```
bash-5.0# mount -o remount,rw -v /
mount: /dev/sda1 mounted on /.
bash-5.0# echo $?
1
```
However:
```
bash-5.0# LD_PRELOAD= mount -o remount,rw -v /
mount: /dev/sda1 mounted on /.
bash-5.0# echo $?
0
```
Further investigation with strace shows a LeakSanitizer error:
```
bash-5.0# strace -s 512 mount -o remount,rw -v /
...
write(2, "==355==LeakSanitizer has encountered a fatal error.\n", 52) = -1 EBADF (Bad file descriptor)
write(2, "ReportFile::Write() can't output requested buffer!\n", 51) = -1 EBADF (Bad file descriptor)
exit_group(1) = ?
+++ exited with 1 +++
```
Let's workaround this by clearing the LD_PRELOAD variable for
systemd-remount-fs.service
This makes the default build much quicker. If people are building systemd for
packaging or actual installation, they probably need to set some more options
anyway (-Ddns-servers=, -Dntp-servers=), so adding -Dman=true is not a big
burden.
For CIs configured locally, -Dman=true is added to restore status quo ante.
Man page generation is generally very slow. I prefer to use -Dman=false when
developing systemd, and only build specific pages when introducing changes.
Those two little helper tools make it easy:
$ build/man/man systemd.link
$ build/man/html systemd.link
will show systemd.link.8 and systemd.link.html from the build directory build/.
Allow users to set the IPv4 DF bit in outgoing packets, or to inherit its
value from the IPv4 inner header. If the encapsulated protocol is IPv6 and
DF is configured to be inherited, always set it.
When VXLAN destination port is unset and GPE is set
then assign 4790 to destination port. Kernel does the same as
well as iproute.
IANA VXLAN-GPE port is 4790
Fillup IFLA_INET6_ADDR_GEN_MODE while we do link_up.
Fixes the following error:
```
dummy-test: Could not bring up interface: Invalid argument
```
After reading the kernel code when we do a link up
```
net/core/rtnetlink.c
IFLA_AF_SPEC
af_ops->set_link_af(dev, af);
inet6_set_link_af
if (tb[IFLA_INET6_ADDR_GEN_MODE])
Here it looks for IFLA_INET6_ADDR_GEN_MODE
```
Since link up we didn't filling up that it's failing.
Closes#12504.
Otherwise, the fuzzers will fail to compile with MSan:
```
../../src/systemd/src/basic/random-util.c:64:40: error: use of undeclared identifier 'sucess'; did you mean 'success'?
msan_unpoison(&success, sizeof(sucess));
^~~~~~
success
../../src/systemd/src/basic/alloc-util.h:169:50: note: expanded from macro 'msan_unpoison'
^
../../src/systemd/src/basic/random-util.c:38:17: note: 'success' declared here
uint8_t success;
^
1 error generated.
[80/545] Compiling C object 'src/basic/a6ba3eb@@basic@sta/process-util.c.o'.
ninja: build stopped: subcommand failed.
Fuzzers build failed
```
These make sense to be explicitly set at 0 (which has a different effect
than the default, since it can affect processing of `DefaultMemoryXXX`).
Without this, it's not easily possible to relinquish memory protection
for a subtree, which is not great.
(before)
$ build/systemctl list-machines
Need to be root.
$ sudo build/systemctl list-machines
NAME STATE FAILED JOBS
krowka (host) running 0 0
rawhide running 0 0
2 machines listed.
(after)
$ build/systemctl list-machines
NAME STATE FAILED JOBS
krowka (host) running 0 0
rawhide n/a 0 0
2 machines listed.
The output for non-root is missing some bits of information, but we display
what information is missing nicely, and e.g. in the case when no machines are
running at all, or only VMs are running, the unprivileged output would be the
same as the privileged one.
The reasoning is the same as in previous cases. We get an error like
"Failed to update EFI variable: Operation not permitted" anyway, so
the check is not very useful.
If we lack permissions, we will fail anyway. But by not doing the artifial
check, we get more information. For example, on my machine, I see
$ build/systemd-bless-boot good
Not booted with boot counting in effect.
while "Need to be root" is actually untrue, because being root doesn't change
the outcome in any way.
Letting the operation fail on the actual error makes it easier to do test runs:
we *know* the command will fail, but we want to see what the first step would
be.
Not doing the articial check makes it also easier to do create alternative
security arrangements, for example where the directories are mounted with
special ownership mode and an otherwise unprivileged user can perform certain
operations.
Checking if we are root on the client side is generally pointless, since the
privileged operation will fail anyway and we can than log what precisly went
wrong.
A check like this makes sense only if:
- we need to do some expensive unprivileged operation before attempting the
privileged operation, and the check allows us avoid wasting resources.
- the privileged operation would fail but in an unclear way.
Neither of those cases applies here.
This fixes calls like 'udevadm control -h' as unprivileged user.
Daniele Medri
Lennart Poettering
Frantisek Sumsal
Zbigniew Jędrzejewski-Szmek
Yu Watanabe
Susant Sahani
Susant Sahani
Evgeny Vereshchagin
Chris Down