I hit a test failure with the `max_gid+1` test. Problem is that we loop
over 0..r, but set `r` again within the loop (to 1). So max_gid is only
set based on the first supplementary GID.
ConditionGroup=1000 → 1
ConditionGroup=4 → 1
ConditionGroup=adm → 1
ConditionGroup=1001 → 1
Assertion 'r == 0' failed at ../src/test/test-condition.c:462, function
test_condition_test_group(). Aborting.
$ id
uid=1000(alan-sysop) gid=1000(alan-sysop) groups=1000(alan-sysop),4(adm),
10(wheel),1001(sshlogin)
/sys is not guaranteed to exist when a new mount namespace is created.
It is only mounted under conditions specified by
`namespace_info_mount_apivfs`.
Checking if the three available MAC LSMs are enabled requires a sysfs
mounted at /sys, so the checks are moved to before a new mount ns is
created.
This changes the symbolic name for the default gateway from "gateway" to
"_gateway". A new configuration option -Dcompat-gateway-hostname=true|false
is added. If it is set, the old name is also supported, but the new name
is used as the canonical name in either case. This is intended as a temporary
measure to make the transition easier, and the option should be removed
after a few releases, at which point only the new name will be used.
The old "gateway" name mostly works OK, but hasn't gained widespread acceptance
because of the following (potential) conflicts:
- it is completely legal to have a host called "gateway"
- there is no guarantee that "gateway" will not be registered as a TLD, even
though this currently seems unlikely. (Even then, there would be no
conflict except for the case when the top-level domain itself was being resolved.
The "gateway" or "_gateway" labels have only special meaning when the
whole name consists of a single label, so resolution of any subdomain
of the hypothetical gateway. TLD would still work OK. )
Moving to "_gateway" avoids those issues because underscores are not allowed
in host names (RFC 1123, §2.1) and avoids potential conflicts with local or
global names.
v2:
- simplify the logic to hardcode "_gateway" and allow
-Dcompat-gateway-hostname=true as a temporary measure.
Cache client metadata, in order to be improve runtime behaviour under
pressure.
This is inspired by @vcaputo's work, specifically:
https://github.com/systemd/systemd/pull/2280
That code implements related but different semantics.
For a longer explanation what this change implements please have a look
at the long source comment this patch adds to journald-context.c.
After this commit:
# time bash -c 'dd bs=$((1024*1024)) count=$((1*1024)) if=/dev/urandom | systemd-cat'
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 11.2783 s, 95.2 MB/s
real 0m11.283s
user 0m0.007s
sys 0m6.216s
Before this commit:
# time bash -c 'dd bs=$((1024*1024)) count=$((1*1024)) if=/dev/urandom | systemd-cat'
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 52.0788 s, 20.6 MB/s
real 0m52.099s
user 0m0.014s
sys 0m7.170s
As side effect, this corrects the journal's rate limiter feature: we now
always use the unit name as key for the ratelimiter.
These are similar to memdup() and newdup(), but reserve one extra NUL
byte at the end of the new allocation and initialize it. It's useful
when copying out data from fixed size character arrays where NUL
termination can't be assumed.
Let's be a bit stricter in what we end up logging: ignore invalid unit
name specifications. Let's validate all input!
As we ignore unit names passed in from unprivileged clients anyway the
effect of this additional check is minimal.
(Also, no need to initialize the identifier/unit_id fields of stream
objects to NULL if empty strings are passed, the default is NULL
anyway...)
When we create a log stream connection to journald, we pass along the
unit ID. With this change we do this only when we run as system
instance, not as user instance, to remove the ambiguity whether a user
or system unit is specified. The effect of this change is minor:
journald ignores the field anyway from clients with UID != 0. This patch
hence only fixes the unit attribution for the --user instance of the
root user.
Checking for validity of a PID is relatively easy, but let's add a
helper cal for this too, in order to make things more readable and more
similar to uid_is_valid(), gid_is_valid() and friends.
Let's add a proper validation function, since validation isn't entirely
trivial. Make use of it where applicable. Also make use of
AUDIT_SESSION_INVALID where we need a marker for an invalid audit
session.
The long man page paragraph got it right: the tool is for escaping systemd unit
names, not just system unit names. Also fix the short man page paragraph
and the --help text.
Follow-up for 303608c1bc
When a service unit uses "ProtectKernelTunables=yes", it currently
remounts /sys/fs/selinux read-only. This makes libselinux report SELinux
state as "disabled", because most SELinux features are not usable. For
example it is not possible to validate security contexts (with
security_check_context_raw() or /sys/fs/selinux/context). This behavior
of libselinux has been described in
http://danwalsh.livejournal.com/73099.html and confirmed in a recent
email, https://marc.info/?l=selinux&m=149220233032594&w=2 .
Since commit 0c28d51ac8 ("units: further lock down our long-running
services"), systemd-localed unit uses ProtectKernelTunables=yes.
Nevertheless this service needs to use libselinux API in order to create
/etc/vconsole.conf, /etc/locale.conf... with the right SELinux contexts.
This is broken when /sys/fs/selinux is mounted read-only in the mount
namespace of the service.
Make SELinux-aware systemd services work again when they are using
ProtectKernelTunables=yes by keeping selinuxfs mounted read-write.
mount_load does not require fragment files to be present in order to
load mount units which are perpetual, or come from /proc/self/mountinfo.
mount_verify should do the same, otherwise a synthesized '-.mount' would
be marked as failed with "No such file or directory", as it is perpetual
but not marked to come from /proc/self/mountinfo at this point.
This happens for the user instance, and I suspect it was the cause of #5375
for the system instance, without gpt-generator.
Comparing udev_device_get_sysname(device) and sysname will always return
true. We need to check the device received from udev monitor instead.
Also, fd_wait_for_event() sometimes never exits. Better set a timeout
here.
We just abort startup, without printing any error. Make sure we always
print something, and when we cannot deserialize some unit, just ignore it and
continue.
Fixup for 4bc5d27b94. Without this, we would hang
in daemon-reexec after upgrade.
Display the error for a small amount of time, but don't fail hard.
In case of a faulty BIOS, a TPM error should not prevent the boot.
If something cares about the PCM measurement, it will be noticed
anyway later on.
Especially important now, that TPM measurement is the default now on
some distribution builds.
https://bugzilla.redhat.com/show_bug.cgi?id=1411156
The option MHD_OPTION_STRICT_FOR_CLIENT is provided since libmicrohttpd-0.9.54, and
MHD_USE_PEDANTIC_CHECKS will be deprecated in future.
This makes support both option.
The option MHD_USE_THREAD_PER_CONNECTION requires MHD_USE_POLL_INTERNAL_THREAD
since libmicrohttpd-0.9.53.
If MHD_USE_POLL is used instead of MHD_USE_POLL_INTERNAL_THREAD, then
the library outputs the following warning:
```
Warning: MHD_USE_THREAD_PER_CONNECTION must be used only with
MHD_USE_INTERNAL_POLLING_THREAD. Flag MHD_USE_INTERNAL_POLLING_THREAD was added.
Consider setting MHD_USE_INTERNAL_POLLING_THREAD explicitly.
```
The option MHD_USE_POLL_INTERNAL_THREAD is defined as
`MHD_USE_POLL_INTERNAL_THREAD = MHD_USE_POLL | MHD_USE_INTERNAL_POLLING_THREAD,`
So, let's use MHD_USE_POLL_INTERNAL_THREAD instead of MHD_USE_POLL.
Some kdbus_flag and memfd related parts are left behind, because they
are entangled with the "legacy" dbus support.
test-bus-benchmark is switched to "manual". It was already broken before
(in the non-kdbus mode) but apparently nobody noticed. Hopefully it can
be fixed later.
Since busname units are only useful with kdbus, they weren't actively
used. This was dead code, only compile-tested. If busname units are
ever added back, it'll be cleaner to start from scratch (possibly reverting
parts of this patch).
Example log:
Jul 22 15:55:21 fedora systemd[1]: a1.service: Found ordering cycle on a2.service/start
Jul 22 15:55:21 fedora systemd[1]: a1.service: Found dependency on a3.service/start
Jul 22 15:55:21 fedora systemd[1]: a1.service: Found dependency on a1.service/start
Jul 22 15:55:21 fedora systemd[1]: a1.service: Job a2.service/start deleted to break ordering cycle starting with a1.service/start
Jul 22 15:55:21 fedora systemd[1]: Starting a1.service...
Jul 22 15:55:21 fedora systemd[1]: Started a1.service.
Example log entry:
Sat 2017-07-22 15:55:21.372389 EDT [s=0004bb6302d94ac3aa69987fb6157338;i=9ae;b=a96eb6153d4f4f3686c7b4
_BOOT_ID=a96eb6153d4f4f3686c7b4db8a432908
_MACHINE_ID=ad18f69b80264b52bb3b766240742383
_HOSTNAME=fedora
PRIORITY=3
SYSLOG_FACILITY=3
SYSLOG_IDENTIFIER=systemd
_UID=0
_GID=0
_PID=1
_TRANSPORT=journal
_CAP_EFFECTIVE=3fffffffff
_COMM=systemd
_EXE=/usr/lib/systemd/systemd
_SYSTEMD_CGROUP=/init.scope
_SYSTEMD_UNIT=init.scope
_SYSTEMD_SLICE=-.slice
_SELINUX_CONTEXT=system_u:system_r:kernel_t:s0
CODE_FILE=../src/core/transaction.c
CODE_FUNC=transaction_verify_order_one
UNIT=a3.service
UNIT=a1.service
UNIT=a2.service
CODE_LINE=430
MESSAGE=a1.service: Job a2.service/start deleted to break ordering cycle starting with a1.service
_CMDLINE=/usr/lib/systemd/systemd --system --deserialize 28
_SOURCE_REALTIME_TIMESTAMP=1500753321372389
This should make it easier to see when any of the units are involved in an
ordering cycle.
Fixes#6336.
v2:
- also update the "Unable to break cycle" message.
This reverts commit 2d058a87ff.
When we add another name to a unit (by following an alias), we need to
reload all drop-ins. This is necessary to load any additional dropins
found in the dirs created from the alias name.
Fixes#6334.
While working on the gateway→_gateway conversion, I noticed that
libidn2 strips the leading underscore in some names.
https://gitlab.com/libidn/libidn2/issues/30 was resolved in
https://gitlab.com/libidn/libidn2/commit/05d753ea69e2308cd02436d0511f4b844071dc79,
which disabled "STD3 ASCII rules" by default, i.e. disabled stripping
of underscores. So the situation is that with previously released libidn2
versions we would get incorrect behaviour, and once new libidn2 is released,
we should be OK.
Let's implement a simple test which checks that the name survives the
roundtrip, and if it doesn't, skip IDN resolution. Under old libidn2 this will
fail in more cases, and under new libidn2 in fewer, but should be the right
thing to do also under new libidn2.
As a follow-up for db3f45e2d2 let's do the
same for all other cases where we create a FILE* with local scope and
know that no other threads hence can have access to it.
For most cases this shouldn't change much really, but this should speed
dbus introspection and calender time formatting up a bit.
Yu Watanabe
Alan Jenkins
Jouke Witteveen
Jan Synacek
Susant Sahani
Lennart Poettering
Fabio Kung
Zbigniew Jędrzejewski-Szmek
Nicolas Iooss
vliaskov
Abdó Roig-Maranges
S. Fan
Andrew Soutar
Martin Pitt
Harald Hoyer