nss-systemd,sysusers: make sure sysusers doesn't get confused by nss-systemd (#6812)
In nss-systemd we synthesize user entries for "nobody" and "root", as
fallback if we boot up with an entirely empty /etc. This is supposed to
be a fallback only though, and it's intended that both users exists
regularly in /etc/passwd + /etc/group. Before this patch
systemd-sysusers would never create the entries however as it notices
the synthetic entries. Let's add a way how systemd-sysusers can tell
nss-systemd not to synthesize the entries for itself.
man: rework grammatical form of sentences in a table in systemd.exec(5)
"Currently, the following values are defined: xxx: in case <condition>" is
awkward because "xxx" is always defined unconditionally. It is _used_ in case
<condition> is true. Correct this and a bunch of other places where the
sentence structure makes it unclear what is the subject of the sentence.
As it turns out the authentication phase times out too often than is
good, mostly due to PRNG pools not being populated during boot. Hence,
let's increase the authentication timeout from 25s to 90s, to cover for
that.
(Note that we leave the D-Bus method call timeout at 25s, matching the
reference implementation's value. And if the auth phase managed to
complete then the pools should be populated enough and mehtod calls
shouldn't take needlessly long anymore).
pager: let's create pager fds with O_CLOEXEC first
We make copies (without O_CLOEXEC) of the fds anyway before using them,
hence let's be safe and create them with O_CLOEXEC first, so that we
don't run into issues should pager_open() be called in a threaded
environment where another thread fork()s at the wrong time and ends up
with fds not marked O_CLOEXEC.
main: skip many initialization steps when running in --test mode
Most importantly, don't collect open socket activation fds when in
--test mode. This specifically created a problem because we invoke
pager_open() beforehand (which these days makes copies of the original
stdout/stderr in order to be able to restore them when the pager goes
away) and we might mistakenly the fd copies it creates as socket
activation fds.
run: add new --pipe option for including "systemd-run" commands in shell pipelines
In this mode, we'll directly connect stdin/stdout/stderr of the invoked
service with whatever systemd-run itself is invoked on. This allows
inclusion of "systemd-run" commands in shell pipelines, as unlike
"--pty" this means EOF of stdin/stdout/stderr are propagated
independently.
If --pty and --pipe are combined systemd-run will automatically pick the
right choice for the context it is invoked in, i.e. --pty when invoked
on a TTY, and --pipe otherwise.
Now that we have ported nspawn's seccomp code to the generic code in
seccomp-util, let's extend it to support whitelisting and blacklisting
of specific additional syscalls.
This uses similar syntax as PID1's support for system call filtering,
but in contrast to that always implements a blacklist (and not a
whitelist), as we prepopulate the filter with a blacklist, and the
unit's system call filter logic does not come with anything
prepopulated.
(Later on we might actually want to invert the logic here, and
whitelist rather than blacklist things, but at this point let's not do
that. In case we switch this over later, the syscall add/remove logic of
this commit should be compatible conceptually.)
Previously we were loading kernel modules on all device events save
for "remove". With the introduction of KOBJ_BIND/KOBJ_UNBIND this causes
issues, as driver modules that have devices bound to their drivers get
immediately reloaded, and it appears to the user that module unloading
does not work.
Let's change the rules to only load modules on "add" events instead.
seccomp: split out inner loop code of seccomp_add_syscall_filter_set()
Let's add a new helper function seccomp_add_syscall_filter_item() that
contains the inner loop code of seccomp_add_syscall_filter_set(). This
helper function we can then export and make use of elsewhere.
In libudev (which es much older code than the rest of systemd), we
propagate errors in functions not returning an int, via (positive) errno
(i.e. libc-style), and as negative Exyz values in those returning an int
(much preferred, i.e. Linux kernel style). Let's fix up a few place,
where this was incorrectly done, or not done at all.
Alan Jenkins [Sat, 9 Sep 2017 12:54:23 +0000 (13:54 +0100)]
man: update reference to definition of StartLimitAction (#6786)
The values for StartLimitAction are defined in `man systemd.unit`.
Don't send people to `man systemd.service` just to find they need to look
back in `man systemd.unit` again :).
core: downgrade log message about inability to propagate cgroup release message
If dbus is already down during shutdown, we can't propagate the cgroup
release message anymore, but that's expected and nothing to warn about.
Hence let's downgrade the message from LOG_WARN to LOG_DEBUG.
Michal Sekletar [Fri, 8 Sep 2017 13:41:44 +0000 (15:41 +0200)]
manager: when reexecuting try to connect to bus only when dbus.service is around (#6773)
Trying to connect otherwise is pointless, because if socket isn't around
we won't connect. However, when dbus.socket is present we attempt to
connect. That attempt can't succeed because we are then supposed
to activate dbus.service as a response to connection from
us. This results in deadlock.
They’re counterparts to the existing set-log-level and set-log-target
verbs, simply printing the current value to stdout. This makes it
slightly easier to temporarily change the log level and/or target and
then restore the old value(s).
assemble multidevice btrfs volumes without external tools (#6607)
assemble multidevice btrfs volumes without external tools
This self-contained approach introduce very little overhead, unless
someone has a large number of devices composing many btrfs volumes,
in which case btrfs device scan would be faster. Still, having robust
implementation is a nice to have alternative for btrfs-progs.
man: Document prefix delegation in systemd.network
Add prefix delegation documentation covering IPv6PrefixDelegation=
setting in the Network section as well as all the parameters and
the IPv6PrefixDelegation and IPv6Prefix sections implemented so
far, including DNS= and DNSLifetimeSec= settings.
units: add remote-cryptsetup.target and remote-cryptsetup-pre.target
The pair is similar to remote-fs.target and remote-fs-pre.target. Any
cryptsetup devices which require network shall be ordered after
remote-cryptsetup-pre.target and before remote-cryptsetup.target.
units: order cryptsetup-pre.target before cryptsetup.target
Normally this happens automatically, but if it happened that both targets were
pulled in, even though there were no cryptsetup units, they could be started
in reverse order, which would be somewhat confusing. Add an explicit ordering
to avoid this potential issue.
Seems to be some kind of confusion in gcc. Insteading of playing whack-a-mole and
adding work-arounds in code, let's adjust the compilation options instead.
projects / thirdparty / systemd.git / log
