Bug 779408

Found bug in the gdm 'passwordless' code, at the beginning, it uses 'gdm' service to create conversation, but later, choose 'gdm-autologin' to handle the password less issue. Thus, it cannot find the conversation correctly. In my testing, it will hang up after choose the user. But sometimes, gdm will behavior like your description, in this situation, gdm did not recognize passwordless setting.

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101
> Firefox/15.0
> 
> It is impossible to log in to a user account if the password login option is
> set to "choose password at next login" or "log in without password" in GNOME
> System Settings.
> 
> Also, there are some selection issues with these options. After selecting
> "choose password at next login", if you then select "log in without password",
> your setting will be reverted. You can disable the account, but if you then
> select "log in without password", it will again revert to "choose password at
> next login". The only way to select "log in without password" at this point is
> to set a password anyway, then select "log in without password."  Your
> selection will now be retained.  (Though you'll still be unable to log in. ^^)
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. Go to System Settings -> User accounts and create a new user account for
> testing.
> 2. Select "log in without password"
> 3. Log out of your current account and attempt to log into the new account.
> 4. GDM will request a password, as if it doesn't realize you do not have one.
> (This might be intentional.) Leave the password field blank. An authentication
> failure will occur.
> 5. Log in to your original account and change the test account to "choose
> password at next login."
> 6. Log out and try to login to the test account. GDM will request a password as
> usual, without prompting for the creation of a new one. Enter anything (since
> you're supposed to be setting your password). An authentication failure will
> occur.
> 7. Log back into your original account and change the setting on the test
> accoutn to "log in without password". Wait about two seconds and the setting
> will revert to "choose password at next login."

Created attachment 505555 [details]
change the service name when start conversation

Patch to fix passwordless bug.
And I cannot reproduce the 'password must be set at next login' bug,
When I login with such account, gdm will ask for 'change password', this is come from the pam module (pam_unix2).

If you login by the console, (tty1 for example) will you see the 'change password' words?

When I log in via tty1 after selecting "choose password at next login" I still get prompted for a password, but no password works, same as when trying to log in via GDM. (This time I forgot to make another user account first, so I had to log in as root to recover.)

The bug is also valid in 12.2, patch submitted to 12.2.

I saw the 'choose password at next login' bug as you described, the old password failed to work, password match failed in the underling pam module. But I cannot reproduce it anymore...  Can you still be able to reproduce it?  Any steps which I can following? 

(In reply to comment #3)
> When I log in via tty1 after selecting "choose password at next login" I still
> get prompted for a password, but no password works, same as when trying to log
> in via GDM. (This time I forgot to make another user account first, so I had to
> log in as root to recover.)

(In reply to comment #5)
> I saw the 'choose password at next login' bug as you described, the old
> password failed to work, password match failed in the underling pam module. But
> I cannot reproduce it anymore...  Can you still be able to reproduce it?  Any
> steps which I can following? 

I've never yet seen this feature work. =/

Here is what I did to reproduce it just now:

1) Using my user account, create a new account:

Full Name: Big Bird
Username: bigbird

2) The account is initially disabled, so assign a password:

Password: bigbird

(Kind of surprised System Settings allowed that password, but whatever.)

3) Log out, attempt to log in to bigbird.

- Attempt 1: GNOME never loads. This was probably random chance though.
- Attempt 2: GNOME loads, all is well.

4) Log into main account, select bigbird in user account settings and select "choose password on next login." Log out.

5) Attempt to log in to bigbird. Type original password. gdm reports authentication failed!

No way to log into bigbird until manually resetting his password.

David, please see the following declined message of the opensuse-review-team. Could you fix the missing description, please and submit it again? Thanks.


Request: #137959

  maintenance_release: openSUSE:Maintenance:1002/gdm.openSUSE_12.2_Update -> openSUSE:12.2:Update/gdm.1002
  maintenance_release: openSUSE:Maintenance:1002/patchinfo -> openSUSE:12.2:Update/patchinfo.1002


Message:
<no message>

State:   declined   2012-10-12T15:34:40 a_jaeger
Comment: The GNOME team has a convention of using a # PATCH description
for each patch in the spec file. Please follow this convention
also for this update.

Thanks,
Andreas

Update released for 12.1 and 12.2. Thanks for the submission again. Resolved fixed.

openSUSE-RU-2012:1384-1: An update that has two recommended fixes can now be installed.

Category: recommended (low)
Bug References: 779408,785152
CVE References: 
Sources used:
openSUSE 12.1 (src):    gdm-3.2.0-5.10.1

openSUSE-RU-2012:1385-1: An update that has two recommended fixes can now be installed.

Category: recommended (low)
Bug References: 779408,785152
CVE References: 
Sources used:
openSUSE 12.2 (src):    gdm-3.4.1-4.10.1

Reopened since login without password was never fixed.

I'm working on a patch that removes it from the UI simply because there's other stuff on the page that's also broken (automatic password generation, password hints).  But I haven't yet found the underlying problem.

Created attachment 519089 [details]
Remove 'password to be set at next login'

This doesn't fix the underlying issue, so the bug should not be closed, but this will stop anyone from accidentally removing their password in the meantime. Conveinent mainly since it can be released with the other g-c-c updates I worked on today. Something smarter from somebody smarter would be grand, though.

Michael, could you create a maintenancerequest with the updated package, please? I'll let review the fixes from one of our maintainers. Thank you very much for your efforts!

Well I think we should not use my patch; this is indeed just a PAM misconfiguration, so we should fix it instead of removing the feature.

Our gdm-password in /etc/pam.d has the following line for auth; everything below auth doesn't matter:

auth     include        common-auth

Here is my common-auth:

auth    required        pam_env.so      
auth    optional        pam_gnome_keyring.so
auth    required        pam_unix2.so

This is wrong for various reasons:

1) pam_unix2 must come before gnome_keyring, not after, or else the keyring will naturally prompt for a password, which would be wrong in this case.

2) pam_unix2 must not be required and must have the nullok option, or else you won't be able to login at all (if you're set to choose password at next login).  Both of these constraints seem "wrong" to me - why should you need nullok just to make setting the password not fail - but that seems to be how it works. 

So this is the best I could come up with (for gdm-password):

auth      required      pam_env.so
auth      sufficient    pam_unix2.so nullok
auth      required      pam_deny.so
auth      optional     pam_gnome_keyring.so

But that's clearly wrong, since it breaks gnome-keyring (you can't reach that last line).

Then I found some old bugs (links below) and came up with this:

auth      required      pam_env.so
auth      substack    gdm-auth
auth      optional     pam_gnome_keyring.so

Where gdm-auth is a new file:

auth      sufficient    pam_unix2.so nullok
auth      required      pam_deny.so

But that does not work either, since now pam_gnome_keyring is prompting for a password again... and so I am completely stumped at what to try next. Furthermore, I wouldn't know how to integrate a solution using pam-config.

Relevant-ish:

https://bugzilla.novell.com/show_bug.cgi?id=443189
https://bugzilla.novell.com/show_bug.cgi?id=477488

CC Vincent since you've worked on this in the past.  This works perfectly on Fedora (I'll attach Fedora's configuration), but they're using authconfig instead of pam-config.

Created attachment 519833 [details]
Fedora's gdm-password config

This works for Fedora, but it's pretty messy.  postlogin is empty.

Created attachment 519834 [details]
Fedora password-auth, generated by authconfig

This is of limited value to us since they use authconfig... but it works so it might help.

"But that does not work either, since now pam_gnome_keyring is prompting for a
password again... and so I am completely stumped at what to try next." At least I guess that's what's happening... seems like auth pam_unix2.so fails when the password is expired, but gnome_keyring isn't aware of that.

I simply don't understand why it works for Fedora.  Their substack setup is basically the same as what I've got, but for them, gnome-keyring shuts up....

Note that password expiry in pam is not related to the auth group, but to the account group.

It might simply be that "chage -d 0" which is being used to force setting password on next login doesn't work like this on openSUSE. Does it actually work if you log in a console (or with "su -")?

Hm, I probably should have tried that. :-)  It indeed does not work; you can't log in on a console when your password has expired and you have no password.  So this is a common-auth bug rather than a gdm bug.  (chage works fine, nothing wrong there.)

If your password is expired and you do somehow have a password set, say by calling passwd -d and then chage -d 0 manually, everything works fine: you're prompted for your current password, enter it, and then are prompted to change it.  The bug is only when you don't have a password at all, which will be "all the time" if you set this from gnome-control-center, because accountsservice calls passwd -d (before chage -d 0) to remove your password when you set the password mode to "choose at next login".  (Which is correct, as otherwise you'd have to first set a password to use the mode, which is self-defeating.)

Also there's nothing (that I see) wrong with our "account" or "password" settings, it's really just the "auth" step that is broken. I guess auth runs before accounts and password regardless, and if authentication fails you're out of luck. Perhaps it's a problem with pam_unix2, which shouldn't ask for a password if the user has none and the password is expired? (?)

This is an autogenerated message for OBS integration:
This bug (779408) was mentioned in
https://build.opensuse.org/request/show/148527 Maintenance /

Nah, third time's the charm: https://build.opensuse.org/request/show/148529

That doesn't fix anything, though.  It just makes sense to remove the option until we figure this out -- if you're new to Linux and run across this, you might not figure out how to log in ever again! -- especially since I'd like to push three other updates to the password dialog. This one is applied as a separate patch that should be easy to revert when fixed.

This is an autogenerated message for OBS integration:
This bug (779408) was mentioned in
https://build.opensuse.org/request/show/148528 Maintenance /

Before this gets accepted as a maintenance update, I feel we should make sure that this is fixed in Factory too (to avoid losing the fixes for 12.3).

In this case:

 - is someone pushing apg to Factory?
 - is gnome-control-center-password-must-change.patch upstreamed?
 - what's the long term plan for fixing the "change at next login" issue?

- is someone pushing apg to Factory?

Not that I know of but it's a nonissue since v3.6 uses libpwquality instead of apg, so it's already fixed.

 - is gnome-control-center-password-must-change.patch upstreamed?

I've responded in https://bugzilla.novell.com/show_bug.cgi?id=779413

 - what's the long term plan for fixing the "change at next login" issue?

I have no idea because I don't know how to fix the PAM issue. =(  It'd be much better if we could fix that, since we would not need this patch at all. I included this temporary workaround in my maintenance request since (1) it fits nicely with the other fixes to the same dialog and is trivial to remove later when PAM gets fixed, and (2) the feature is totally useless and purely dangerous until then.

Thanks for the answers! I'm happy with the update, then :-)

Do we have a bug to track the pam issue?

I think that's this one. :-)  I was just planning to reopen it after the maintenance update.  Would it be better to make a new one?

(Should we assign it to the base system team?)

(In reply to comment #26)
> I think that's this one. :-)  I was just planning to reopen it after the
> maintenance update.  Would it be better to make a new one?
> 
> (Should we assign it to the base system team?)

I think a new one would be better (as this one as lots of comments already). It should be assigned to the maintainer of pam (osc maintainer openSUSE:Factory pam)

Er, a bit late to be noticing this - but passwordless login still doesn't work either.  Which is slightly expected since there is no nullok on pam_unix2.so.  Peter does it work for you?

sudo /usr/sbin/pam-config --update --nullok fixes it....

Opened bug https://bugzilla.novell.com/show_bug.cgi?id=798939

Also revoked mr https://build.opensuse.org/request/show/148529 since this is a major flaw.  =/

I see what is the difference, my previous attempts were based on Yast -- user account manager -- choose 'force password change'. In the console login, you can verify it. gdm works after applying my patch.

In Yast, the old password was preserved, the expire date was changed to '0'.
In system setting (accountservice), the expire data was changed to '0', however old password was cleaned.
Pam authenticated policy will verify the old password and ask the user to set the new password. In system setting, as the old password was cleaned, pam failed to authenticate the password.

(In reply to comment #30)
> In Yast, the old password was preserved, the expire date was changed to '0'.
> In system setting (accountservice), the expire data was changed to '0', however
> old password was cleaned.
> Pam authenticated policy will verify the old password and ask the user to set
> the new password. In system setting, as the old password was cleaned, pam
> failed to authenticate the password.

Good point. It's probably a bug in accountsservice that it removes the old password first. This shouldn't be needed.

The code to fix is http://cgit.freedesktop.org/accountsservice/tree/src/user.c#n1396

Keeping the password will not break any existing use-cases that I can think of, so that's a reasonable first step.

Hi,
I get some other opinions while reading this code.

'*PASSWORD_MODE_NONE' in the system setting (gnome-control-center-user-accounts) code means 'passwordless'. But it is not implemented in accountsservice yet.

In Yast/account-setting, it is 'implemented', but the concept is different. In Yast, when we use passwordless login, we simply enable all the accounts from passwordless login. In System Setting, we just enable the selected account from passwordless login. 

This difference means: in Yast, we need to save the passwordless setting in a system configuration file(/etc/sysconfig/displaymanager); but in System Setting, it aims to be saved separately.

From the code, the author supposes that the underlining pam module accepts an empty password input if the password preserved was null. Thus both the 'passwordless login' and 'set at next login' implementations are reasonable. I think it is a good assumption, changing the pam module according to this has some advantages:

1) gdm don't need to use 'gdm-autologin' to implement the passwordless function anymore. Even this file could be removed from gdm package, when a user were set to 'autologin', it would just be one of the passwordless login accounts and marked as AUTOLOGIN in /etc/sysconfig/displaymanager meanwhile. 
2) 'password less' makes an account real password less but not use pam-permit.so to always return 'ok'. Just like 'disable an account', do disable the account other than, for example, using pam-forbit.so to always return 'fail'.

(In reply to comment #31)> 
> The code to fix is
> http://cgit.freedesktop.org/accountsservice/tree/src/user.c#n1396

(In reply to comment #33)
> Hi,
> I get some other opinions while reading this code.

I was just talking about the "set password at next login" option. Passwordless is a different matter, indeed.

*** Bug 798939 has been marked as a duplicate of this bug. ***

This seems to me to be an issue of conflicting designs. There's really no point in trying to find workarounds for the broken settings, IMO, as they are broken by design - Thorsten simply doesn't want you to be able to authenticate without a password (the YaST/sysconfig option being the senseless exception).

I see the following options: (a) change the common PAM configuration, (b) ignore the common PAM configuration, or (c) simply remove the options from g-c-c.

Alternatively we could remove "login without password" and still try to save "choose password at next login" by using the change to accountsservice proposed above. It will kind of work, but it's not sufficient in itself in that (a) we'd still have to patch g-c-c to hide the option when the user currently has no password, and (b) you're prompted for your current password twice (once to authenticate, once to start the password change process) which is non-ideal.

(By the way, the presence of the sysconfig options is silly and complicating. Why would you want to enable passwordless login for ALL accounts when you could instead enable it selectively for each one....)

Vincent, I think it would be a good idea to just remove the broken UI for the time being -- does that sound good?

(In reply to comment #37)
> Vincent, I think it would be a good idea to just remove the broken UI for the
> time being -- does that sound good?

As long as the right fixes are being worked on for the long term, that's fine with me.

I submitted fixes for 12.1 and 12.2 (and I'll get them to GNOME:Factory ASAP) so I think I'd better state what I see as being long-term (13.1) fixes:

* YaST already allows passwordless login, but for the display manager only. So giving gdm custom PAM configuration to allow login without password should be fine. (The user still needs authentication in order to remove his password, anyway.)

* Login without password, we might need to work with upstream to convince them that accountsservice it should not remove any current password. And then we might need a patch for ourselves to hide the option if the user does not currently have a password.

openSUSE-RU-2013:0331-1: An update that has four recommended fixes can now be installed.

Category: recommended (low)
Bug References: 779408,779413,779414,796932
CVE References: 
Sources used:
openSUSE 12.2 (src):    gnome-control-center-3.4.2-3.15.1
openSUSE 12.1 (src):    gnome-control-center-3.2.1-2.10.1

This is an autogenerated message for OBS integration:
This bug (779408) was mentioned in
https://build.opensuse.org/request/show/158145 Maintenance /

Update released for openSUSE 12.3. Resolved fixed.