currently if a stub image is directly booted, bootctl reports:
```
Current Loader:
Product: n/a
ESP: /dev/disk/by-partuuid/b0a0807d-0592-40e9-adac-3bb724e9e305
File: └─/EFI/Secure/secure-boot-4.14.8+.efi
```
Let's add a StubInfo which will be displayed by bootctl too (in a later
patch).
when an image with the stub is booted directly from UEFI, bootctl status
shows this:
```
Current Loader:
Product: n/a
ESP: /dev/disk/by-partuuid/b0a0807d-0592-40e9-adac-3bb724e9e305
File: └─n/a
```
After this change, the stub reports the image itself:
```
Current Loader:
Product: n/a
ESP: /dev/disk/by-partuuid/b0a0807d-0592-40e9-adac-3bb724e9e305
File: └─/EFI/Secure/secure-boot-4.14.8+.efi
```
Currently there is no way to prevent tests from building using meson.
This introduces two problems:
1) It adds a extra 381 files to compile.
2) One of these tests explicitly requires libgcrypt to be built even if systemd
is not using it.
3) It adds C++ to the requirements to build systemd.
When cross-compiling, this is uneccessary.
Testing the previous commit with `systemctl stop tmp.mount` logged the
reason for failure as expected, but unexpectedly the message was repeated
32 times.
The retry is a special case for umount; it is only supposed to cover the
case where the umount command was _successful_, but there was still some
remaining mount(s) underneath. Fix it by making sure to test the first
condition :).
Re-tested with and without a preceding `mount --bind /mnt /tmp`,
and using `findmnt` to check the end result.
That way, they're always sorted by date. I do not know how to make ZSH sort
them by PID through some option, but that doesn't seem very useful in the first
place.
An output from coredumpctl list is like
> TIME PID UID GID SIG COREFILE EXE
> Sun 2016-05-29 18:44:03 CEST 14578 1000 1000 6 none /tmp/pacaurtmp-wieland/python33/src/Python-3.3.6/python
^1 ^2 ^3 ^4 ^5
, but the previous sub() command turns that into
> TIMEPID UID GID SIG COREFILE EXE
> Sun2016-05-29 18:44:03 CEST 14578 1000 1000 6 none /tmp/pacaurtmp-wieland/python33/src/Python-3.3.6/python
^1 ^2 ^3 ^4 ^5
so the whole pipeline generated entries like
$UID:$DESCRIPTION
but that's not useful and probably not what was supposed to happen.
This now generates entries like
$PID:$DESCRIPTION
which make everything work.
Note that with this commmit, the completions will be sorted by PID by
ZSH.
Documentation - systemd.exec - strongly implies mount units get logging.
It is safe for mounts to depend on systemd-journald.socket. There is no
cyclic dependency generated. This is because the root, -.mount, was
already deliberately set to EXEC_OUTPUT_NULL. See comment in
mount_load_root_mount(). And /run is excluded from being a mount unit.
Nor does systemd-journald depend on /var. It starts earlier, initially
logging to /run.
Tested before/after using `systemctl stop tmp.mount`.
in other way we will get a warning during build:
../src/core/dbus-util.h:55:13: warning: ‘bus_set_transient_errno’
defined but not used [-Wunused-function]
int bus_set_transient_##function(
When we crash we freeze() our-self (or possibly we reboot the machine if
that is configured). However, calling pause() is very unhelpful thing to
do. We should at least continue to do what init systems being doing
since 70's and that is reaping zombies. Otherwise zombies start to
accumulate on the system which is a very bad thing. As that can prevent
admin from taking manual steps to reboot the machine in somewhat
graceful manner (e.g. manually stopping services, unmounting data
volumes and calling reboot -f).
Fixes#7783
On Linux the former is a compat alias to the latter, and that's really
weird, as inside the kernel the two are distinct. Which means we really
should stay away from it.
Let's be more restrictive when validating PID files and MAINPID=
messages: don't accept PIDs that make no sense, and if the configuration
source is not trusted, don't accept out-of-cgroup PIDs. A configuratin
source is considered trusted when the PID file is owned by root, or the
message was received from root.
This should lock things down a bit, in case service authors write out
PID files from unprivileged code or use NotifyAccess=all with
unprivileged code. Note that doing so was always problematic, just now
it's a bit less problematic.
When we open the PID file we'll now use the CHASE_SAFE chase_symlinks()
logic, to ensure that we won't follow an unpriviled-owned symlink to a
privileged-owned file thinking this was a valid privileged PID file,
even though it really isn't.
Fixes: #6632
The new --uid= switch allows selecting the UID from which the
notificaiton messages shall originate.
This is primarily useful for testing purposes, but might have other
uses.
Let's be explicit, and always send the messages from our UID and never
our EUID. Previously this behaviour was conditionalized only on whether
the PID was specified, which made this non-obvious.
If we have to chose between truncated escape sequences and strings
exploded to 4 times the desried length by fully escaping, prefer the
latter.
It's for debug only, hence doesn't really matter much.
The new flag returns the O_PATH fd of the final component, which may be
converted into a proper fd by open()ing it again through the
/proc/self/fd/xyz path.
Together with O_SAFE this provides us with a somewhat safe way to open()
files in directories potentially owned by unprivileged code, where we
want to refuse operation if any symlink tricks are played pointing to
privileged files.
When the flag is specified we won't transition to a privilege-owned
file or directory from an unprivileged-owned one. This is useful when
privileged code wants to load data from a file unprivileged users have
write access to, and validates the ownership, but want's to make sure
that no symlink games are played to read a root-owned system file
belonging to a different context.
Дамјан Георгиевски
Lennart Poettering
Дилян Палаузов
Yu Watanabe
Adam Duskett
Zbigniew Jędrzejewski-Szmek
Alan Jenkins
Wieland Hoffmann
0xAX
Max Harmathy
Michal Sekletar
Franck Bui
Matthew Thode
winnerman-pythian