diff --git a/30846.patch b/30846.patch new file mode 100644 index 0000000..84a4163 --- /dev/null +++ b/30846.patch @@ -0,0 +1,55 @@ +From 07fd822c59e29b4f5e7dab029ea1186c1b862e3e Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= +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; + } diff --git a/systemd.spec b/systemd.spec index 14f79f7..1400ccc 100644 --- a/systemd.spec +++ b/systemd.spec @@ -109,9 +109,11 @@ Patch0001: https://github.com/systemd/systemd/pull/26494.patch # Those are downstream-only patches, but we don't want them in packit builds: # https://bugzilla.redhat.com/show_bug.cgi?id=1738828 Patch0490: use-bfq-scheduler.patch +# https://bugzilla.redhat.com/show_bug.cgi?id=2251843 +Patch0491: https://github.com/systemd/systemd/pull/30846.patch # Adjust upstream config to use our shared stack -Patch0491: fedora-use-system-auth-in-pam-systemd-user.patch +Patch0499: fedora-use-system-auth-in-pam-systemd-user.patch %ifarch %{ix86} x86_64 aarch64 %global want_bootloader 1