(RHEL-70103) journal: again create user journals for users with high uids #305
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This effectively reverts a change in 115d514 '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. Upstream PR: systemd/systemd#30846 rhel-only: bugfix Resolves: RHEL-70103
github-actions
bot
changed the title
github-actions
bot
added
pr/needs-ci
Commit validationTracker - RHEL-70103 The following commits meet all requirements
Tracker validationSuccess🟢 Tracker RHEL-70103 has set desired product: Pull Request validationSuccess🟡 CI - Waived Auto MergeSuccess🟢 Pull Request is not marked as draft and it's not blocked by |
github-actions
bot
added
tracker/missing
|
CI failures are unrelated to these changes: |
github-actions
bot
merged commit abe0be8
into
redhat-plumbers:main
27 of 30 checks passed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This effectively reverts a change in 115d514 '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.
Upstream PR: systemd/systemd#30846
rhel-only: bugfix
Resolves: RHEL-70103