I changed imports of util.h to initrd-util.h, or added an import of
initrd-util.h, to keep compilation working. It turns out that many files didn't
import util.h directly.
When viewing the patch, don't be confused by git rename detection logic:
a new .c file is added and two functions moved into it.
flock(2) works with file descriptors opened with O_RDONLY.
This affects SELinux systems where access to block devices is quite
restricted to avoid bypasses on filesystem objects.
Since f7725647bb when dissecting a disk
image we operate with fds to the device nodes in question wherever we
can. This includes when we fork off fsck, where we pass a /proc/self/fd/
path as argument. This only works if we keep that fd open however and
disable O_CLOEXEC on the fd. Hence do so, and fix fsck this way.
(Without this, all fsck will fail, since the fd path is invalid)
In the Xen case, it's the hypervisor which manages kexec. We thus
have to ask it whether a kernel is loaded, instead of relying on
/sys/kernel/kexec_loaded.
Instead of succeeding when either the firmware reports a TPM device
or we find a TPM device, let's check that the firmware reports a TPM
device and the TPM subsystem is enabled in the kernel.
To check whether the subsystem enabled, we check if the relevant
subdirectory in /sys exists at all.
To support predictable interface names in various embeeded systems
add support for an additional naming scheming using the USB host
interface. Several asics have usb controllers that are platform
devices and not children of a pci interface. These embedded systems
should be able to enumerate interfaces by udev path as well to support
configurations and policies.
Signed-off-by: Charles Hardin <charles.hardin@chargepoint.com>
We treat symlinks to unit files outside of the search path differently from
symlinks to unit files *in* the search path. The former are "linked" unit
files, while the latter are enablement symlinks and such and will be removed
when disabling the unit.
The history of the check for in_search_path() is interesting: this condition
was added already in the first version of the code in
830964834f. Since the beginning, matching
arguments would simply be ignored. I think this is dubious. The man page says:
> Link a unit file that is *not* in the unit file search paths
> into the unit file search path
But for backwards-compat, let's continue to silently do nothing for files
*in* the search path.
The case of symlinks to unit files underneath the search path, but in some
subdirectory, is less clear. We didn't check for this case, so it was
implicitly allowed. But that's just an oversight, we don't want to allow people
to create additional subhierarchies under our hierarchy. Let's check for this
case and refuse.
Closes#24605.
This adds a check for an allocation error for the calls to install_changes_add()
where we're plannig to return success from the call. In cases where we're
returning failure, it doesn't matter as much: the operation will fail anyway,
and if the allocation fails, we'll just get a less descriptive error message.
The machinery to report a good error message only works if the
error was registered with install_changes_add() and a file name. Otherwise
we only get a generic "Op failed: %m" message.
In some places -EINVAL is replaced by -EUCLEAN, so that we get the proper
error message.
The function was written to only return an error from internal allocation
failures, because when using it to create a bus message, we want to distinguish
a failed operation from an allocation error when sending the reply. But it
turns out that the only caller that makes this distinction checks that the
passed-in errno value ('type') is not negative beforehand. So we can make the
function pass 'type' value through, which makes most of the callers nicer.
No functional change.
We would deadlock when passing the data back from the forked-off process that
was doing backtrace generation back to the coredump parent. This is because we
fork the child and wait for it to exit. The child tries to write too much data
to the output pipe, and and after the first 64k blocks on the parent because
the pipe is full. The bug surfaced in Fedora because of a combination of four
factors:
- 87707784c7 was backported to v251.5, which
allowed coredump processing to be successful.
- 1a0281a3eb was NOT backported, so the output
was very verbose.
- Fedora has the ELF package metadata available, so a lot of output can be
generated. Most other distros just don't have the information.
- gnome-calendar crashes and has a bazillion modules and 69596 bytes of output
are generated for it.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2135778.
The code is changed to try to write data opportunistically. If we get partial
information, that is still logged. In is generally better to log partial
backtrace information than nothing at all.
(s) is just ugly with a vibe of DOS. In most cases just using the normal plural
form is more natural and gramatically correct.
There are some log_debug() statements left, and texts in foreign licenses or
headers. Those are not touched on purpose.
We list plenty of arch-specific syscalls in our filter groups, treat the
s390 syscalls the same.
We handle gracefully anyway if some syscall doesn't exist locally on the
kernel or arch, let's rely on it. This has the benefit that
"systemd-analyze" will comprehensively tell you the syscalls filtered on
any arch for any arch.
And less conditionalization is good anyway.
Attempt to address
https://github.com/systemd/systemd/issues/20330#issuecomment-1210028422.
Summary of the comment: Unprivileged users can potentially cause a denial of
service during systemd-oomd unit subscriptions by spamming requests to
SubscribeManagedOOMCGroups. As systemd-oomd.service is the only unit that
should be accessing this method, add a check on the caller's unit name to deter
them from successfully using this method.
Using _SOURCE_{MONOTONIC,REALTIME}_TIMESTAMP in place of the results of
sd_journal_get_{monotonic,realtime}_usecs in export formats might cause
internal inconsistency of realtime timestamp values within a journal export,
violating the export file format and causing systemd-journal-remote to
mass-generate journal files.
Fix this by using the real journal timestamps for
__{REALTIME,MONOTONIC}_TIMESTAMP.
Typically the _MAX and _INVALID special enum values use the full type as
prefix, even if the actual values of the enum might not. Let's follow
this rule here too.
We can just make this an enum, as long as we ensure it has enough range,
which we can do by adding -ERRNO_MAX as one possible value (at least on
GNU C). We already do that at multiple other places, so let's do this
here too.
'systemctl unmask foo' will try to remove the symlink to /dev/null under /etc/.
But the unit may also be masked by a symlink under /run/generator, in particular
the one created by systemd-debug-generator based on systemd.mask=foo on the
kernel commandline. The unmask call cannot anything about this: even if it removed
the symlink from /run/generator, it'll be recreated on the next daemon-reload.
Thus, we can only warn about it.
Initially, I wanted to check if 'systemctl.mask' is defined on the kernel
command-line, but that's not effective, because such mask symlinks can be
created by other generators based on other conditions. Checking for runtime
mask is "dumber", but is more robust because it doesn't assume who created the
mask and why.
The handling of InstallInfo is the copied from install_info_symlink_wants().
It's pretty ugly, this whole code should be rewritten from scratch.
The message is printed, but the whole operation is still "successful". This
keep backwards compatibility: people might call unmask to remove filesystem
masks even if there's still a cmdline param in place. We allow 'systemctl
mask' to create such a mask, so 'unmask' should be able to remove it.
Fixes#22689.
We had an anonymous enum with values called UNIT_FILE_…, which could easily be
confused with UNIT_FILE_… from UnitFileFlags enum. This commit renames the enum
values and also the variables which refer to them.