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.
Quoting https://github.com/systemd/systemd/pull/25050#discussion_r998721845:
This part seems to be quite racy, at least in the C8S job:
[ 1767.520856] H testsuite-15.sh[35]: *** test transient slice drop-ins
[ 1767.520856] H testsuite-15.sh[35]: + mkdir -p /etc/systemd/system/slice.d
[ 1767.522480] H testsuite-15.sh[35]: + mkdir -p /etc/systemd/system/a-.slice.d
[ 1767.524992] H testsuite-15.sh[35]: + mkdir -p /etc/systemd/system/a-b-.slice.d
[ 1767.526799] H testsuite-15.sh[35]: + mkdir -p /etc/systemd/system/a-b-c.slice.d
[ 1767.528302] H testsuite-15.sh[35]: + echo -e '[Unit]\nDocumentation=man:drop1'
[ 1767.528434] H testsuite-15.sh[35]: + echo -e '[Unit]\nDocumentation=man:drop2'
[ 1767.528519] H testsuite-15.sh[35]: + echo -e '[Unit]\nDocumentation=man:drop3'
[ 1767.528595] H testsuite-15.sh[35]: + echo -e '[Unit]\nDocumentation=man:drop4'
[ 1767.528676] H testsuite-15.sh[35]: + systemctl cat a-b-c.slice
[ 1767.541321] H systemctl[1042]: No files found for a-b-c.slice.
[ 1767.542854] H systemd[1]: testsuite-15.service: Main process exited, code=exited, status=1/FAILURE
[ 1767.542995] H systemd[1]: testsuite-15.service: Failed with result 'exit-code'.
[ 1767.543360] H systemd[1]: Failed to start testsuite-15.service.
[ 1767.543542] H systemd[1]: testsuite-15.service: Consumed 1.586s CPU time.
[ 1767.543938] H systemd[1]: Reached target testsuite.target.
[ 1767.545737] H systemd[1]: Starting end.service...
Let's document that "." is a bad choice of character when naming
interfaces. Let's also document the hard restrictions we make when
naming interfaces.
Result of the mess that is #25052.
* chore: enable scorecard action
* chore: add badge to the README file
* chore: enable on config file update
* chore: update scorecard to 2.0.4
* chore: run scorecard on PR at main branch
* chore: add condition to publish_result key
* chore: skip upload to code scanning if PR
* chore: only runs scorecard in the main repo
Resolves: #25042
The man page says nothing about "e". Glibc clearly accepts it without fuss, but
it is meaningless for a memory object (and probably doesn't work). This use is
not portable, so let's avoid it.
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.
We do not provide any numerical libraries, and iszero_safe() is only
used in parsing or formatting JSON. Hence, it is not necessary for us to
request that the function provides the same result on different systems.
Fixes#25044.
Use target process context to set socket context when using SELinuxContextFromNet
not systemd's context. Currently when using the SELinuxContextFromNet option for
a socket activated services, systemd calls getcon_raw which returns init_t and
uses the resulting context to compute the context to be passed to the
setsockcreatecon call. A socket of type init_t is created and listened on and
this means that SELinux policy cannot be written to control which processes
(SELinux types) can connect to the socket since the ref policy allows all
'types' to connect to sockets of the type init_t. When security accessors see
that any process can connect to a socket this raises serious concerns. I have
spoken with SELinux contributors in person and on the mailing list and the
consensus is that the best solution is to use the target executables context
when computing the sockets context in all cases.
[zjs review/comment:
This removes the branch that was added in 16115b0a7b.
16115b0a7b did two things: it had the branch here
in 'socket_determine_selinux_label()' and a code in 'exec_child()' to call
'label_get_child_mls_label(socket_fd, command->path, &label)'.
Before this patch, the flow was:
'''
mac_selinux_get_child_mls_label:
peercon = getpeercon_raw(socket_fd);
if (!exec_label)
exec_label = getfilecon_raw(exe);
socket_open_fds:
if (params->selinux_context_net) #
label = mac_selinux_get_our_label(); # this part is removed
else #
label = mac_selinux_get_create_label_from_exe(path);
socket_address_listen_in_cgroup(s, &p->address, label);
exec_child():
exec_context = mac_selinux_get_child_mls_label(fd, executable, context->selinux_context);
setexeccon(exec_context);
'''
]
Similarly to DumpByFileDescriptor vs Dump,
DumpUnitsMatchingPatternsByFileDescriptor is used in preference. Dissimilarly,
a fallback to DumpUnitsMatchingPatterns is not done on error, because there is
no need for backwards compatibility.
The code is still more verbose than I'd like, but there are four different code
paths with slightly different rules in each case, so it's hard to make this all
very brief. Since we have a separate file dedicated to making those calls, the
verbose-but-easy-to-follow implementation should be OK.
Closes#24989.
I only did a quick test that all both variants works locally and over ssh.
Otherwise we might hit a race where we read the test log just before
it's fully written to the disk:
```
======================================================================
FAIL: test_interleaved (__main__.ExecutionResumeTest.test_interleaved)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/root/systemd/test/test-exec-deserialization.py", line 170, in test_interleaved
self.check_output(expected_output)
File "/root/systemd/test/test-exec-deserialization.py", line 111, in check_output
self.assertEqual(output, expected_output)
AssertionError: 'foo\n' != 'foo\nbar\n'
foo
+ bar
```
With some debug:
```
test_interleaved (__main__.ExecutionResumeTest.test_interleaved) ...
Assertion failed; file contents just after the assertion:
b'foo\n'
File contents 5 seconds later:
b'foo\nbar\n'
FAIL
```
Seen quite often in CentOS CI on the fast baremetal machines.
(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.
TEST-69 uses a Python wrapper around the systemd-nspawn call, which on
error calls the `spawn.terminate()` method. However, with no arguments
it will only use SIGHUP and SIGINT signals - this might leave a stuck
container around, causing fails if the test is run again. With `force=True`
SIGKILL is used as well (if necessary).
This moves the shim security arch override to the new
ReinstallProtocolInterface based interface. This also has the benefit to
reduce the time window in which we have this override active and also
actually removes it, which was not previously done.
The shim hooks themselves are also modernized too. The upcalls should
really not be neccessary if shim is happy with the provided binary.
