Bug 495924 - regression in gdm-2.26.0-8: invalid username or password
regression in gdm-2.26.0-8: invalid username or password
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: authconfig (Show other bugs)
rawhide
All Linux
low Severity high
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
:
: 496470 (view as bug list)
Depends On:
Blocks: F11Preview
  Show dependency treegraph
 
Reported: 2009-04-15 11:25 EDT by Andrew McNabb
Modified: 2013-01-10 00:10 EST (History)
8 users (show)

See Also:
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 09:38:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Andrew McNabb 2009-04-15 11:25:25 EDT
I'm getting an "invalid username or password" error when I log in when using gdm-2.16.0-8.  The only relevant log message I could find was in /var/log/secure:

Apr 15 09:04:55 prodigy pam: gdm-password[2952]: pam_unix(gdm-password:auth): au
thentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=  user=amcnabb

Restarting gdm didn't help.  I then downgraded to gdm-2.16.0-7 and was able to log in again.  Anyway, I figured I should let someone know about the problem.  Thanks.
Comment 1 Matthias Clasen 2009-04-15 21:11:42 EDT
Ray, 2.26.0-8 introduced your 'less boring' multistack patch...
Comment 2 Thomas Woerner 2009-04-16 12:31:01 EDT
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.
Comment 3 Thomas Woerner 2009-04-16 12:57:27 EDT
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.
Comment 4 Ray Strode [halfline] 2009-04-16 13:38:43 EDT
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
Comment 5 Jesse Keating 2009-04-16 15:02:40 EDT
Is this only affecting existing (rawhide?) installs or is it new installs, or upgrades from previous releases?

Putting on Preview.
Comment 6 Tomas Mraz 2009-04-16 15:20:22 EDT
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.
Comment 7 Andrew McNabb 2009-04-16 16:02:51 EDT
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?
Comment 8 Tomas Mraz 2009-04-16 16:45:02 EDT
If you update by yum authconfig is not run at all.
Comment 9 Jesse Keating 2009-04-16 16:50:15 EDT
If authconfig needs to be ran when things are updated, why isn't it in there a %post or %posttrans?
Comment 10 Tomas Mraz 2009-04-17 02:44:10 EDT
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.
Comment 11 Andrew McNabb 2009-04-17 03:34:16 EDT
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.
Comment 12 Tomas Mraz 2009-04-17 03:56:08 EDT
(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.
Comment 13 Ray Strode [halfline] 2009-04-22 15:12:48 EDT
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.
Comment 14 Ray Strode [halfline] 2009-04-23 09:34:58 EDT
*** Bug 496470 has been marked as a duplicate of this bug. ***
Comment 15 Ray Strode [halfline] 2009-04-23 09:37:30 EDT
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)
Comment 16 Andrew McNabb 2009-04-23 11:11:26 EDT
I just tested the updated rpm, and it seemed to work.  This will go into F11 Preview, right?
Comment 17 Tom "spot" Callaway 2009-04-23 12:38:57 EDT
Yeah, its been tagged into dist-f11.
Comment 18 Jesse Keating 2009-04-23 12:51:47 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.