Let's lock the personality to the currently set one, if nothing is
specifically specified. But do so with a grain of salt, and never
default to any exotic personality here, but only PER_LINUX or
PER_LINUX32.
Add LockPersonality boolean to allow locking down personality(2)
system call so that the execution domain can't be changed.
This may be useful to improve security because odd emulations
may be poorly tested and source of vulnerabilities, while
system services shouldn't need any weird personalities.
> glibc exports a function called sync(), we should probably avoid
> overloading that as a variable here locally (gcc even used to warn about
> that, not sure why it doesn't anymore), to avoid confusion around what
> "if (sync)" actually means
This helps prevent symbol collisions with other programs and libraries. In particular,
because PAM modules are loaded into the process that is creating the session, and
systemd creates PAM sessions, the potential for collisions is high.
Disambiguate all systemd calls by tagging a 'version' SD_SHARED.
Fixes#6624
`journalctl -o export | systemd-journal-remote -o /tmp/dir -`
gives the following error messages.
```
Failed to open output journal /tmp/dir: Invalid argument
Failed to get writer for source stdin: Invalid argument
Failed to create source for fd:0 (stdin): Invalid argument
```
And these are hard to understand what is the problem.
This commit makes journal-remote check whether the output file name
ends with .journal suffix or not, and if not, output error message.
This commit fixes crash described in
https://github.com/systemd/systemd/issues/6533
Multiple ExecStart lines are allowed only for oneshot services
anyway so it doesn't make sense to call service_run_next_main() with
services of type other than SERVICE_ONESHOT.
Referring back to reproducer from the issue, previously we didn't observe
this problem because s->main_command was reset after daemon-reload hence
we never reached the assert statement in service_run_next_main().
Fixes#6533
Following commit b498d6ea, I belated realized we should tighten the
assertions as well, to make sure that we're setting `m->action_what` to
represent an action in progress. (The check for an action in progress is
to compare `m->action_what` to zero)
This fixed https://bugzilla.redhat.com/show_bug.cgi?id=1476313
as much as I was able to reproduce it in a VM, at least.
E.g. this signal might wake the screen back up, providing a more visible
indicator of suspend failure. In my VM testing, it was also required in
order to unblock keyboard input in gnome-shell after the failed suspend.
At the same time, fix the error handling for scheduled shutdowns. This now
mirrors the behaviour of when you use `shutdown -k` - it sends all the
scary messages about shutting down, "but you'll have to do it [shut down
the system] yourself". It also avoids the risk of locking out the admin
(nologin file), in case they logged out for some reason (and they use
`sudo` instead of root).
Not that I have any idea why you'd want to use `shutdown -k`, but the code
is easier to analyze if it rolls back on error (in the absence of any code
comment as to why that's not wanted).
There is no justification not to wait an extra (default) 5 seconds, for
a more graceful shutdown of user programs. Again, you don't get to ignore
delay inhibitors for unscheduled shutdowns, short of
`systemctl poweroff -f`.
It is simplest if we move the test for `m->shutdown_dry_run` into
manager_scheduled_shutdown_handler().
However we need to not add such delays during a "dry run". Otherwise, we
would still have to be considered "in progress" for some seconds after our
admin has seen the final wall message. If they go to `poweroff`, we would
have blocked them with a misleading error message. Note this `poweroff`
will still process delay inhibitors as needed. If the admin planned to
use a more forceful method... eh. It's their responsibility to assess
whether that's safe.
There is an argument that the alternative behaviour could be used (racily!)
to kludge around them not being able to shutdown to "single user mode". If
we cared about that case, we would have easily preserved non-racy support
for it in `shutdown`.
Additionally, though I think this code does read more easily by reducing
inconsistencies, we didn't come up with any use case for delay inhibitors
v.s. shutdown.[1] The SIGTERM v.s. SIGKILL delay is more general, and we
allow a whole 90 seconds for it, not just 5. So I don't think keeping this
approach bears a risk of significant damage.
[1] https://www.freedesktop.org/wiki/Software/systemd/inhibit/
> We don't want to shutdown while a suspend is running, and vice versa.
> This would be confusing and could lead to data loss in the worst case.
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1441253/comments/4
According to the above comment, if the conflicting operation is hung,
we don't want to force things when the admin has not passed a force option.
Similarly if you're not an admin, you probably shouldn't get to sneak
around this check by using a scheduled shutdown instead of an unscheduled
one. (And no-one so far thought it necessary to add such a permission in
PolKit).
Note that if the conflicting operation was _not_ hung, and we lost the
race with suspend, the system might not have shut down at the scheduled
time anyway. Which is no good if you were scheduling a power outage.
And scheduling a shutdown for an arbitrary time when the system is resumed,
does not seem a very useful semantic. More likely, scheduled shutdowns are
useful on systems which do not use suspend, such as multi-user servers.
(In which case even PolKit defaults likely don't let the users trigger
suspend).
For files which are vital to boot
1. Avoid opening any window where power loss will zero them out or worse.
I know app developers all coded to the ext3 implementation, but
the only formal documentation we have says we're broken if we actually
rely on it. E.g.
* `man mount`, search for `auto_da_alloc`.
* http://www.linux-mtd.infradead.org/faq/ubifs.html#L_atomic_change
* https://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/
2. If we tell the kernel we're interested in writing them to disk, it will
tell us if that fails. So at minimum, this means we play our part in
notifying the user about errors.
I refactored error-handling in `udevadm-hwdb` a little. It turns out I did
exactly the same as had already been done in the `systemd-hwdb` version,
i.e. commit d702dcd.
One of the benefits of updating a file "atomically", is to avoid losing the
old version. For example, if we run out of disk space half-way through.
Fix localed to enjoy this benefit.
Since hotplugs happen as soon as udevd is started, there is not much sense
in giving udev-trigger an After= dependency on any service. The device
could be hotplugged before coldplug starts.
This is intended to avoid the race window where we create the hwdb with
the wrong selinux context (then fix it up afterwards).
https://github.com/systemd/systemd/issues/3458#issuecomment-322444107
