feat: Add systemd package with system extension patch

staging/systemd/10-map-count.conf

@@ -0,0 +1,3 @@
+# Increase the number of virtual memory areas that one process may request
+# https://fedoraproject.org/wiki/Changes/IncreaseVmMaxMapCount
+vm.max_map_count=1048576

staging/systemd/10-oomd-defaults.conf

@@ -0,0 +1,2 @@
+[OOM]
+DefaultMemoryPressureDurationSec=20s

staging/systemd/10-oomd-per-slice-defaults.conf

@@ -0,0 +1,3 @@
+[Slice]
+ManagedOOMMemoryPressure=kill
+ManagedOOMMemoryPressureLimit=80%

staging/systemd/10-timeout-abort.conf

@@ -0,0 +1,14 @@
+# This file is part of the systemd package.
+# See https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer.
+#
+# To facilitate debugging when a service fails to stop cleanly,
+# TimeoutStopFailureMode=abort is set to "crash" services that fail to stop in
+# the time allotted. This will cause the service to be terminated with SIGABRT
+# and a coredump to be generated.
+#
+# To undo this configuration change, create a mask file:
+#   sudo mkdir -p /etc/systemd/system/service.d
+#   sudo ln -sv /dev/null /etc/systemd/system/service.d/10-timeout-abort.conf
+
+[Service]
+TimeoutStopFailureMode=abort

staging/systemd/20-yama-ptrace.conf

@@ -0,0 +1,42 @@
+# The ptrace system call is used for interprocess services,
+# communication and introspection (like synchronisation, signaling,
+# debugging, tracing and profiling) of processes.
+#
+# Usage of ptrace is restricted by normal user permissions. Normal
+# unprivileged processes cannot use ptrace on processes that they
+# cannot send signals to or processes that are running set-uid or
+# set-gid. Nevertheless, processes running under the same uid will
+# usually be able to ptrace one another.
+#
+# Fedora enables the Yama security mechanism which restricts ptrace
+# even further. Sysctl setting kernel.yama.ptrace_scope can have one
+# of the following values:
+#
+# 0 - Normal ptrace security permissions.
+# 1 - Restricted ptrace. Only child processes plus normal permissions.
+# 2 - Admin-only attach. Only executables with CAP_SYS_PTRACE.
+# 3 - No attach. No process may call ptrace at all. Irrevocable.
+#
+# For more information see Documentation/security/Yama.txt in the
+# kernel sources.
+#
+# The default is 1., which allows tracing of child processes, but
+# forbids tracing of arbitrary processes. This allows programs like
+# gdb or strace to work when the most common way of having the
+# debugger start the debuggee is used:
+#    gdb /path/to/program ...
+# Attaching to already running programs is NOT allowed:
+#    gdb -p ...
+# This default setting is suitable for the common case, because it
+# reduces the risk that one hacked process can be used to attack other
+# processes. (For example, a hacked firefox process in a user session
+# will not be able to ptrace the keyring process and extract passwords
+# stored only in memory.)
+#
+# Developers and administrators might want to disable those protections
+# to be able to attach debuggers to existing processes. Use
+#   sysctl kernel.yama.ptrace_scope=0
+# for change the setting temporarily, or copy this file to
+# /etc/sysctl.d/20-yama-ptrace.conf to set it for future boots.
+
+kernel.yama.ptrace_scope = 0

staging/systemd/30846.patch

@@ -0,0 +1,55 @@
+From 07fd822c59e29b4f5e7dab029ea1186c1b862e3e Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= <[email protected]>
+Date: Tue, 9 Jan 2024 11:28:04 +0100
+Subject: [PATCH] journal: again create user journals for users with high uids
+
+This effectively reverts a change in 115d5145a257c1a27330acf9f063b5f4d910ca4d
+'journald: move uid_for_system_journal() to uid-alloc-range.h', which slipped
+in an additional check of uid_is_container(uid). The problem is that that change
+is not backwards-compatible at all and very hard for users to handle.
+There is no common agreement on mappings of high-range uids. Systemd declares
+ownership of a large range for container uids in https://systemd.io/UIDS-GIDS/,
+but this is only a recent change and various sites allocated those ranges
+in a different way, in particular FreeIPA uses (used?) uids from this range
+for human users. On big sites with lots of users changing uids is obviously a
+hard problem. We generally assume that uids cannot be "freed" and/or changed
+and/or reused safely, so we shouldn't demand the same from others.
+
+This is somewhat similar to the situation with SYSTEM_ALLOC_UID_MIN /
+SYSTEM_UID_MAX, which we tried to define to a fixed value in our code, causing
+huge problems for existing systems with were created with a different
+definition and couldn't be easily updated. For that case, we added a
+configuration time switch and we now parse /etc/login.defs to actually use the
+value that is appropriate for the local system.
+
+Unfortunately, login.defs doesn't have a concept of container allocation ranges
+(and we don't have code to parse and use those nonexistent names either), so we
+can't tell users to adjust logind.defs to work around the changed definition.
+
+login.defs has SUB_UID_{MIN,MAX}, but those aren't really the same thing,
+because they are used to define where the add allocations for subuids, which is
+generally a much smaller range. Maybe we should talk with other folks about
+the appropriate allocation ranges and define some new settings in login.defs.
+But this would require discussion and coordination with other projects first.
+
+Actualy, it seems that this change was needed at all. The code in the container
+does not log to the outside journal. It talks to its own journald, which does
+journal splitting using its internal logic based on shifted uids. So let's
+revert the change to fix user systems.
+
+Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2251843.
+---
+ src/basic/uid-alloc-range.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/basic/uid-alloc-range.c b/src/basic/uid-alloc-range.c
+index 669cb6d56f7be..7b724b7959f60 100644
+--- a/src/basic/uid-alloc-range.c
++++ b/src/basic/uid-alloc-range.c
+@@ -127,5 +127,5 @@ bool uid_for_system_journal(uid_t uid) {
+
+         /* Returns true if the specified UID shall get its data stored in the system journal. */
+
+-        return uid_is_system(uid) || uid_is_dynamic(uid) || uid == UID_NOBODY || uid_is_container(uid);
++        return uid_is_system(uid) || uid_is_dynamic(uid) || uid == UID_NOBODY;
+ }

staging/systemd/33738.patch

@@ -0,0 +1,37 @@
+From 69c5d6bea7cc2168a2a483d232aa9a77202173f0 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <[email protected]>
+Date: Tue, 16 Jul 2024 17:46:09 +0200
+Subject: [PATCH] rules: Add uaccess tag to /dev/udmabuf
+
+In some cases userspace may need to create dmabuffers from userspace
+on such example is the software ISP part of libcamera which needs to
+allocate dma-buffers for the output of the software ISP.
+
+At first the plan was to allow console users access to /dev/dma_heap/*,
+this was discussed with various kernel folks here:
+https://lore.kernel.org/all/[email protected]/
+
+Giving console users access to the dma_heap's was deemed a bad idea
+because memory allocated this way is not accounted in cgroup limits.
+
+Giving access to /dev/udmabuf OTOH was deemed acceptable so that
+is what this patch adds.
+
+Resolves: #32662
+---
+ rules.d/70-uaccess.rules.in | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/rules.d/70-uaccess.rules.in b/rules.d/70-uaccess.rules.in
+index b82ce04a39d38..e683bb1114461 100644
+--- a/rules.d/70-uaccess.rules.in
++++ b/rules.d/70-uaccess.rules.in
+@@ -34,6 +34,8 @@ SUBSYSTEM=="sound", TAG+="uaccess", \
+ SUBSYSTEM=="video4linux", TAG+="uaccess"
+ SUBSYSTEM=="dvb", TAG+="uaccess"
+ SUBSYSTEM=="media", TAG+="uaccess"
++# libcamera software ISP used with some cams requires udmabuf access
++KERNEL=="udmabuf", TAG+="uaccess"
+
+ # industrial cameras, some webcams, camcorders, set-top boxes, TV sets, audio devices, and more
+ SUBSYSTEM=="firewire", TEST=="units", ENV{IEEE1394_UNIT_FUNCTION_MIDI}=="1", TAG+="uaccess"