Bug 495924
| Summary: | regression in gdm-2.26.0-8: invalid username or password | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Andrew McNabb <amcnabb> |
| Component: | authconfig | Assignee: | Ray Strode [halfline] <rstrode> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | dcantrell, jmccann, mclasen, oded, rstrode, tcallawa, tmraz, twoerner |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | authconfig-5.4.10-1.fc11 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-04-23 13:38:34 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 476775 | ||
|
Description
Andrew McNabb
2009-04-15 15:25:25 UTC
Ray, 2.26.0-8 introduced your 'less boring' multistack patch... Same for me: gdm-2.26.0-8.fc11 and gdm-2.26.1-1.fc11 are not working, but gdm-2.26.0-7 does. I am using kerberos for user authentication and am starting an icewm session. This seems to be the result of using the new pam configuration gdm-password, which is using password-auth, which does not know about kerberos and co. unfortunately authconfig isn't updating the new password-auth file to match the system configuration on upgrades. running authconfig --updateall should work around the bug Is this only affecting existing (rawhide?) installs or is it new installs, or upgrades from previous releases? Putting on Preview. This does not affect new installs. It will affect upgrades when the user has some non-local (krb5, ldap) authentication enabled. yum upgrades are in the case above always affected - and I don't see a way to avoid that - so we should add a relnote to run authconfig --updateall. anaconda upgrades will be affected if the call of authconfig from anaconda does not change any PAM settings. Anaconda could change to use --updateall when calling authconfig though. And I also saw that it will now enable fingerprint auth by default, so the anaconda upgrades should be fine for all users who did not enable fingerprint auth by themselves. So to conclude I don't think this is so serious problem and apart from some really ugly hacks I don't see a way how to fix it in authconfig. Not being able to log in is pretty serious. At that point, it's hard to go back and double check the release notes. Is there a reason the authconfig rpm doesn't use the system settings when it creates the password-auth-ac file in the first place? If you update by yum authconfig is not run at all. If authconfig needs to be ran when things are updated, why isn't it in there a %post or %posttrans? Because if the user modified the configuration by-hand it would overwrite their changes. I am really not too fond of calling 'authconfig --updateall' automatically except from anaconda where the user should revisit his customizations after the upgrade anyway. Also which package should include the call in the %post? authconfig itself? The access to the machine is not blocked completely, you can still log-in with ssh or text console login also if you have a local account on the machine it won't be affected. I think that authconfig (the package that owns system-auth-ac and password-auth-ac) should run authconfig. On my system, the files system-auth-ac and password-auth-ac start with the message: # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. If the user wants to make changes, aren't they supposed to delete the symlink from password-auth to password-auth-ac and make their changes to password-auth? In this case, I think that running authconfig in %post wouldn't break their configuration. (In reply to comment #11) > I think that authconfig (the package that owns system-auth-ac and > password-auth-ac) should run authconfig. On my system, the files > system-auth-ac and password-auth-ac start with the message: > > # This file is auto-generated. > # User changes will be destroyed the next time authconfig is run. > > If the user wants to make changes, aren't they supposed to delete the symlink > from password-auth to password-auth-ac and make their changes to password-auth? Not delete, but point it to elsewhere. > In this case, I think that running authconfig in %post wouldn't break their > configuration. Note that authconfig --updateall will update all of the configuration files authconfig may possibly write. Not only the PAM configuration. So running it always would probably bring more pain than it would solve. But I could put the call to a trigger so it will be run only when upgrading from older version of authconfig. Really I need to fix my patch to make --update work with the new files and then we can add the %post snippet it to do --update instead of --updateall. --update will only update the bits that have changed I think. *** Bug 496470 has been marked as a duplicate of this bug. *** Given this breaks upgrades, we should probably block the preview release for this (or at a minimum do a release note with the work around) I just tested the updated rpm, and it seemed to work. This will go into F11 Preview, right? Yeah, its been tagged into dist-f11. But it wasn't until after today's rawhide compose, which I'm trying to use as the release candidate for Preview, so it may not make it. |