core: resolve binary names immediately before execution
This has two advantages:
- we save a bit of IO in early boot because we don't look for executables
which we might never call
- if the executable is in a different place and it was specified as a
non-absolute path, it is OK if it moves to a different place. This should
solve the case paths are different in the initramfs.
Since the executable path is only available quite late, the call to
mac_selinux_get_child_mls_label() which uses the path needs to be moved down
too.
Similar to free_and_replace. I think this should be uppercase to make it
clear that this is a macro. free_and_replace should probably be uppercased
too.
Other tools silently ignore non-executable names found in path. By checking
F_OK, we would could pick non-executable path even though there is an executable
one later.
core/load-fragment: don't treat "; ;" as "/usr/bin/;"
We had a special test case that the second semicolon would be interpreted
as an executable name. We would then try to find the executable and rely
on ";" not being found to cause ENOEXEC to be returned. I think that's just
crazy. Let's treat the second semicolon as a separator and ignore the
whole thing as we would whitespace.
test-execute: include test location in error output
test-execute is quite long and even with the test name it takes a moment
to find the relevant spot when something fails. Let's make things easier
by printing the exact location.
dissect: show partition output even if os-release is missing
It's just too useful to immediately see with "systemd-dissect" what
"systemd-repart" generated for us without having to populate it with
/etc/os-release. Hence let's log a message if /etc/os-release is
missing, but proceed otherwise and show the partition table.
dissect: always invalidate secondary arch partitions if we found primary arch
Let's suppress the secondary arch data, since we never ever want to
mount it if we found the primary arch.
Previously we only suppressed in the Verity case, but there's little
reason to entertain the idea of a secondary arch in non-Verity
environments either, we are not going to use them, and should not do
decryption or anything like that.
Different bios version includes different pn. Submitted change fixed my inverted screen after reboot.
I've stepped back to the bios version 5.11 28.04.2016 in an attempt to troubleshoot Windows Hello locking the sign
in on reboot. The screen again rotated, but 90 degrees to the right. I created a new hwdb line to resolve that issue. The bios version changes the dmi string including the svn and pn.
dissect: wrap verity settings in new VeritySettings structure
Just some refactoring: let's place the various verity related parameters
in a common structure, and pass that around instead of the individual
parameters.
Also, let's load the PKCS#7 signature data when finding metadata
right-away, instead of delaying this until we need it. In all cases we
call this there's not much time difference between the metdata finding
and the loading, hence this simplifies things and makes sure root hash
data and its signature is now always acquired together.
Peter Hutterer [Thu, 17 Sep 2020 03:06:19 +0000 (13:06 +1000)]
udev: if a tablet has BTN_0, label it as ID_INPUT_TABLET_PAD
Graphics tablet devices comprise multiple event nodes, usually a Pen, Finger
and Pad node (that's how the kernel postfixes them). Pen and Pad are labeled
as ID_INPUT_TABLET but the pad doesn't actually send stylus events - it
doesn't usually have BTN_TOOL_PEN, merely BTN_STYLUS.
For the last several years, libwacom has set ID_INPUT_TABLET_PAD for all pad
devices known to it based on vid/pid and a "* Pad" name match. That does not
cover devices not in libwacom. libinput relies on ID_INPUT_TABLET_PAD to
initialize the pad backend.
We can't drop ID_INPUT_TABLET without breaking userspace, but we can add
ID_INPUT_TABLET_PAD ourselves - where a device has BTN_0 in addition to
BTN_STYLUS, let's add it as a pad.
There are some devices (notably: bamboos) that use BTN_LEFT instead of BTN_0
but they are relatively rare and there's a risk of mislabeling those devices,
so let's just stick with BTN_0 only.
3e5f04bf6468fcb79c080f02b0eab08f258bff0c was trying to do the right thing, but
the resulting list does not match the autogenerated order (which is the same as
the order in vtable definition). I assume the addition was done manually. Fix
the order so that dbus-docs-fresh test is not unhappy.
meson: RC_LOCAL_SCRIPT_PATH_START to RC_LOCAL_PATH
RC_LOCAL_SCRIPT_PATH_START and RC_LOCAL_SCRIPT_PATH_STOP were was originally
added in the conversion to meson based on the autotools name. In 44508946534eee032927c263b79464832656dd6e RC_LOCAL_SCRIPT_PATH_STOP was dropped.
We don't need to use such a long name.
By settings AI_ADDRCONFIG in hints we cannot for example resolve "localhost"
when the local machine only has a loopback interface. This seems like an
unnecessary restriction, drop it.
Inspired by https://bugzilla.redhat.com/show_bug.cgi?id=1839007.
Topi Miettinen [Sun, 30 Aug 2020 18:56:13 +0000 (21:56 +0300)]
exec: SystemCallLog= directive
With new directive SystemCallLog= it's possible to list system calls to be
logged. This can be used for auditing or temporarily when constructing system
call filters.
---
v5: drop intermediary, update HASHMAP_FOREACH_KEY() use
v4: skip useless debug messages, actually parse directive
v3: don't declare unused variables with old libseccomp
v2: fix build without seccomp or old libseccomp
Topi Miettinen [Wed, 5 Aug 2020 13:31:26 +0000 (16:31 +0300)]
exec: Add kill action to system call filters
Define explicit action "kill" for SystemCallErrorNumber=.
In addition to errno code, allow specifying "kill" as action for
SystemCallFilter=.
---
v7: seccomp_parse_errno_or_action() returns -EINVAL if !HAVE_SECCOMP
v6: use streq_ptr(), let errno_to_name() handle bad values, kill processes,
init syscall_errno
v5: actually use seccomp_errno_or_action_to_string(), don't fail bus unit
parsing without seccomp
v4: fix build without seccomp
v3: drop log action
v2: action -> number
tree-wide: don't needlessly negate error number passed to bus_error_message()
Like it's customary in our codebase bus_error_message() internally takes
abs() of the passed error anyway, hence no need to explicitly negate it.
We mostly got this right, but in too many cases we didn't. Fix that.