Add a fido_id program meant to be run for devices in the hidraw
subsystem via an IMPORT directive. The program parses the HID report
descriptor and assigns the ID_SECURITY_TOKEN environment variable if a
declared usage matches the FIDO_CTAPHID_USAGE declared in the FIDO CTAP
specification. This replaces the previous approach of whitelisting all
known security token models manually.
This commit is accompanied by a test suite and a fuzzer target for the
descriptor parsing routine.
Fixes: #11996.
The use of an unordered hashmap means that the output of
'journalctl --update-catalog' differs between runs despite there being no
changes in the input files.
By changing all instances of Hashmap to OrderedHashmap we fix this, and now
the catalog is reproducible.
Motivation: https://reproducible-builds.org
Signed-off-by: Daniel Edgecumbe <git@esotericnonsense.com>
We would not send the property because we'd call sd_bus_get_current_message()
which would return NULL. If there is no message, we cannot support /self or
/auto, but things are still OK if a path with a session name is given.
Traceback when the issue is triggered:
#2 we'd call sd_bus_get_current_message() here, which would return NULL, and
session_object_find() would immediately return 0.
#3 0x00000000004289b7 in session_object_find (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2",
interface=0x9efda0 "org.freedesktop.login1.Session", userdata=0x9852f0, found=0x7ffe3e975fe8, error=0x7ffe3e9760b0)
at ../src/login/logind-session-dbus.c:620
#4 0x00007ff74bfdde39 in node_vtable_get_userdata (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2",
c=0x9f6d58, userdata=0x7ffe3e976070, error=0x7ffe3e9760b0) at ../src/libsystemd/sd-bus/bus-objects.c:37
#5 0x00007ff74bfe49af in emit_properties_changed_on_interface (bus=0x9f1110,
prefix=0xa133a0 "/org/freedesktop/login1/session", path=0xa160b0 "/org/freedesktop/login1/session/c2",
interface=0x43f9f8 "org.freedesktop.login1.Session", require_fallback=true, found_interface=0x7ffe3e976163,
names=0x7ffe3e9761b0) at ../src/libsystemd/sd-bus/bus-objects.c:2088
#6 0x00007ff74bfe56a4 in sd_bus_emit_properties_changed_strv (bus=0x9f1110,
path=0xa160b0 "/org/freedesktop/login1/session/c2", interface=0x43f9f8 "org.freedesktop.login1.Session",
names=0x7ffe3e9761b0) at ../src/libsystemd/sd-bus/bus-objects.c:2291
#7 0x00000000004292ea in session_send_changed (s=0xa16e10, properties=0x43ee27 "Active")
at ../src/login/logind-session-dbus.c:730
#8 0x0000000000424cd7 in seat_set_active (s=0x9ee280, session=0xa16e10) at ../src/login/logind-seat.c:249
#9 0x00000000004251cf in seat_active_vt_changed (s=0x9ee280, vtnr=3) at ../src/login/logind-seat.c:361
#10 0x000000000042547b in seat_read_active_vt (s=0x9ee280) at ../src/login/logind-seat.c:395
#11 0x000000000040ab5c in manager_dispatch_console (s=0x9f0320, fd=8, revents=8, userdata=0x9852f0)
at ../src/login/logind.c:588
#12 0x00007ff74c042d5f in source_dispatch (s=0x9f0320) at ../src/libsystemd/sd-event/sd-event.c:2828
#13 0x00007ff74c04469f in sd_event_dispatch (e=0x9ef340) at ../src/libsystemd/sd-event/sd-event.c:3241
#14 0x00007ff74c044b58 in sd_event_run (e=0x9ef340, timeout=18446744073709551615)
at ../src/libsystemd/sd-event/sd-event.c:3299
#15 0x000000000040d7e8 in manager_run (m=0x9852f0) at ../src/login/logind.c:1186
#16 0x000000000040db58 in run (argc=1, argv=0x7ffe3e976728) at ../src/login/logind.c:1234
#17 0x000000000040dc30 in main (argc=1, argv=0x7ffe3e976728) at ../src/login/logind.c:1244
Fixes#13437. Bug introduced in 3b92c086a8.
This fixes the following problem:
> At the very end of the boot, just after the first user logs in
> (usually using sddm / X) I get the following messages in my logs:
> Nov 18 07:02:33 samd dbus-daemon[2879]: [session uid=1000 pid=2877] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1
> Nov 18 07:02:33 samd dbus-daemon[2879]: [session uid=1000 pid=2877] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1
These messages are caused by the "stub" service files that systemd
installs. It installed them because early versions of systemd activation
required them to exist.
Since dbus 1.11.0, a dbus-daemon that is run with --systemd-activation
automatically assumes that o.fd.systemd1 is an activatable
service. As a result, with a new enough dbus version,
/usr/share/dbus-1/services/org.freedesktop.systemd1.service and
/usr/share/dbus-1/system-services/org.freedesktop.systemd1.service should
become unnecessary, and they can be removed.
dbus 1.11.0 was released 2015-12-02.
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914015
This reverts commit 2de9b9793b.
This check causes regressions, in particular our own units fail. Apparently, it
is enough for the unit to be referenced enough times:
$ journalctl -b -u systemd-ask-password-console.path
Aug 30 12:08:14 krowka systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped.
Aug 30 12:08:33 krowka systemd[1]: systemd-ask-password-console.path: Start request repeated too quickly.
Aug 30 12:08:33 krowka systemd[1]: Failed to start Dispatch Password Requests to Console Directory Watch.
$ journalctl -b -u systemd-firstboot.service
-- Logs begin at Sun 2019-04-21 12:39:21 CEST, end at Fri 2019-08-30 12:23:06 CEST. --
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in First Boot Wizard being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in First Boot Wizard being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in First Boot Wizard being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in First Boot Wizard being skipped.
Aug 30 12:08:33 krowka systemd[1]: systemd-firstboot.service: Start request repeated too quickly.
Aug 30 12:08:33 krowka systemd[1]: Failed to start First Boot Wizard.
And the same for other units.
Fixes#13434.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935829
In a current VirtualBox installation the board_vendor is set to "Oracle
Corporation". So we need to add this to the dmi_vendor_table for a
relieable detection.
This fixes#13429
Signed-off-by: Jan Losinski <losinski@wh2.tu-dresden.de>
This matches what is done in networkd very closely. In fact even the
policy descriptions are all identical (with s/network/resolve), except
for the last one:
resolved has org.freedesktop.resolve1.revert while
networkd has org.freedesktop.network1.revert-ntp and
org.freedesktop.network1.revert-dns so the description is a bit different.
This doesn't matter much, but let's just do the loop once and allocate
the populate the result set on the fly. If we find an error, it'll get
cleaned up automatically.
https://bugzilla.redhat.com/show_bug.cgi?id=1746057
This only affects systemd-resolved. bus_open_system_watch_bind_with_description()
is also used in timesyncd, but it has no methods, only read-only properties, and
in networkd, but it annotates all methods with SD_BUS_VTABLE_UNPRIVILEGED and does
polkit checks.
When booting with Fedora-Server-dvd-x86_64-30-20190411.n.0.iso,
/proc/cmdline is empty (libvirt, qemu host with bios, not sure if that
matters), after installation to disk, anaconda would "crash" in kernel-core
%posttrans, after calling kernel-install, because dracut would fail
with
> Could not determine the kernel command line parameters.
> Please specify the kernel command line in /etc/kernel/cmdline!
I guess it's legitimate, even if unusual, to have no cmdline parameters.
Two changes are done in this patch:
1. do not fail if the cmdline is empty.
2. if /usr/lib/kernel/cmdline or /etc/kernel/cmdline are present, but
empty, ignore /proc/cmdline. If there's explicit configuration to
have empty cmdline, don't ignore it.
The same change was done in dracut:
https://github.com/dracutdevs/dracut/pull/561.
Traditionally, user logins had a $PATH in which /bin was before /sbin, while
root logins had a $PATH with /sbin first. This allows the tricks that
consolehelper is doing to work. But even if we ignore consolehelper, having the
path in this order might have been used by admins for other purposes, and
keeping the order in user sessions will make it easier the adoption of systemd
user sessions a bit easier.
Fixes#733.
https://bugzilla.redhat.com/show_bug.cgi?id=1744059
OOM handling in manager_default_environment wasn't really correct.
Now the (theorertical) malloc failure in strv_new() is handled.
Please note that this has no effect on:
- systems with merged /bin-/sbin (e.g. arch)
- when there are no binaries that differ between the two locations.
E.g. on my F30 laptop there is exactly one program that is affected:
/usr/bin/setup -> consolehelper.
There is less and less stuff that relies on consolehelper, but there's still
some.
So for "clean" systems this makes no difference, but helps with legacy setups.
$ dnf repoquery --releasever=31 --qf %{name} --whatrequires usermode
anaconda-live
audit-viewer
beesu
chkrootkit
driftnet
drobo-utils-gui
hddtemp
mate-system-log
mock
pure-ftpd
setuptool
subscription-manager
system-config-httpd
system-config-rootpassword
system-switch-java
system-switch-mail
usermode-gtk
vpnc-consoleuser
wifi-radar
xawtv
When we would iterate over the lookup paths for each unit, making the list as
short as possible was important for performance. With the current cache, it
doesn't matter much. Two classes of paths were being removed:
- paths which don't exist in the filesystem
- paths which symlink to a path earlier in the search list
Both of those points cause problems with the caching code:
- if a user creates a directory that didn't exist before and puts units there,
now we will notice the new mtime an properly load the unit. When the path
was removed from list, we wouldn't.
- we now properly detect whether a unit path is on the path or not.
Before, if e.g. /lib/systemd/system, /usr/lib/systemd/systemd were both on
the path, and /lib was a symlink to /usr/lib, the second directory would be
pruned from the path. Then, the code would think that a symlink
/etc/systemd/system/foo.service→/lib/systemd/system/foo.service is an alias,
but /etc/systemd/system/foo.service→/usr/lib/systemd/system/foo.service would
be considered a link (in the systemctl link sense).
Removing the pruning has a slight negative performance impact in case of
usr-merge systems which have systemd compiled with non-usr-merge paths.
Non-usr-merge systems are deprecated, and this impact should be very small, so
I think it's OK. If it turns out to be an issue, the loop in function that
builds the cache could be improved to skip over "duplicate" directories with
same logic that the cache pruning did before. I didn't want to add this,
becuase it complicates the code to improve a corner case.
Fixes#13272.
*We* control the sysctl setting. If the user configured IPv6, then we apply the
settings, and just make sure that at some point during the configuration the
sysctl is disabled (i.e. ipv6 enabled) if we have IPv6 configured.
Replaces #13283.
journalctl --unit= already did this, and allows you to tail all the logs
for a certain slice easily. It seemed only natural to make --user-unit
behave in a similar way.
The _SYSTEMD_USER_SLICE field was not documented as being added by
journald, so I have added that to the documentation too.
Furthermore, I have documented the existing behaviour of --unit= and the
new behaviour of --user-unit=
The behaviour was actually not documented before, so I am also OK with
removing the match for the --unit= command instead. The user would then
have to manually provide _SYSTEMD_SLICE= filter to journalctl in both
cases. Both options work for me.
If logging disappears issues are hard to debug, hence let's give
journald a slight edge over other services when the OOM killer hits.
Here are the special adjustments we now make:
systemd-coredump@.service.in OOMScoreAdjust=500
systemd-journald.service.in OOMScoreAdjust=-250
systemd-udevd.service.in OOMScoreAdjust=-1000
(i.e. the coredump processing is made more likely to be killed on OOM,
and udevd and journald are less likely to be killed)
Fabian Henneke
Michael Olbrich
Daniel Edgecumbe
nikolas
Zbigniew Jędrzejewski-Szmek
Your Name
Yu Watanabe
Dimitri John Ledkov
Michael Biebl
Jan Losinski
Arian van Putten
Susant Sahani
Anita Zhang
Lennart Poettering