OCPBUGS-83830: Apply password only if changes exist#5889
OCPBUGS-83830: Apply password only if changes exist#5889pablintino wants to merge 2 commits intoopenshift:mainfrom
Conversation
This change fixes the issue in SSH keys and user passwords that made the rollback useless as it tried to apply the new configuration instead of the previous one. Signed-off-by: Pablo Rodriguez Nava <git@amail.pablintino.eu>
|
Pipeline controller notification For optional jobs, comment This repository is configured in: LGTM mode |
|
@pablintino: This pull request references Jira Issue OCPBUGS-83830, which is invalid:
Comment The bug has been updated to refer to the pull request using the external bug tracker. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: openshift/coderabbit/.coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughThe update flow restricts password-hash changes to the Changes
Sequence Diagram(s)(omitted) Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 10 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (10 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Review rate limit: 9/10 reviews remaining, refill in 6 minutes. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@pkg/daemon/update.go`:
- Around line 1252-1255: The passwd-section diff currently triggers
SetPasswordHash even when only SSH keys changed; add a targeted comparison that
detects real password-hash intent changes and use that to guard SetPasswordHash
and the related passwd-handling block (the code that currently checks
diff.passwd). Implement a helper like passwordHashChanged(newUsers, oldUsers)
that normalizes nil/empty to a placeholder and compares per-user password hashes
(and detects removed users with a non-placeholder old hash), then replace the
diff.passwd condition with a call to this helper before invoking
dn.SetPasswordHash (and likewise for the block at the other occurrence around
the SetPasswordHash usage) so usermod -p runs only when hashes actually changed.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: fbb6ae67-6748-4e2a-86f0-63abfdbe9764
📒 Files selected for processing (1)
pkg/daemon/update.go
|
/test unit |
This bugfix ensures that the MCD only runs `usermod` if the password hash has actually changed and not in every update. This aligns the behavior we currently have for SSH passwords. Signed-off-by: Pablo Rodriguez Nava <git@amail.pablintino.eu>
fdfe7de to
867a618
Compare
|
/test unit |
yuqi-zhang
left a comment
There was a problem hiding this comment.
/lgtm
Left some thoughts inline but logically should be sound
| defer func() { | ||
| if retErr != nil { | ||
| if err := dn.updateSSHKeys(newIgnConfig.Passwd.Users, oldIgnConfig.Passwd.Users); err != nil { | ||
| if err := dn.updateSSHKeys(oldIgnConfig.Passwd.Users, newIgnConfig.Passwd.Users); err != nil { |
There was a problem hiding this comment.
Good thing this almost never fails since we probably never had a functional rollback
| } | ||
|
|
||
| // Check if hash update is needed. Skip if not. | ||
| currentHash, err := getUserPasswordHash(u.Name) |
There was a problem hiding this comment.
So the vast majority of users would never have this set. I guess with our current logic, we'd always just be doing a usermod with an empty password hash and this is triggering the policy described in the bug?
I'm wondering if we just exit out of this function if passwordhash is unset. I guess we'd have to have special logic if the user deletes a password entry, so probably fine to keep it as is since most users wouldn't be hitting this with your conditional changes above.(just thinking if we can bypass the ondisk check)
There was a problem hiding this comment.
Yeah, I thought about it, but I took the "Ansible" approach. "I'd do my best to make your state match the machine state". With an early exit or check, the user would be able to modify the node shadow and we won't never try to patch it to match the MC, that I'd say it's the sourth of true.
|
Scheduling tests matching the |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: pablintino, yuqi-zhang The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@pablintino: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
Closes: #OCPBUGS-83830
- What I did
This bugfix ensures that the MCD only runs
usermodif the password hash has actually changed and not in every update. This aligns the behavior we currently have for SSH passwords.- How to verify it
TBD
- Description for the changelog
This bugfix ensures that the MCD only runs
usermodif the password hash has actually changed and not in every update.Summary by CodeRabbit