| Summary: | Asked for password three times when changing it via pam_winbind | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | David Woodhouse <dwmw2> |
| Component: | samba | Assignee: | Guenther Deschner <gdeschner> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 21 | CC: | abokovoy, asn, dwmw2, gdeschner, jlieskov, sbose, ssorce, steved, tmraz |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-12-02 02:57:31 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
David Woodhouse
2013-09-12 09:29:12 UTC
That pam_unix asks for the password is not a real problem. The problem is that the password should be set into PAM_OLDAUTHTOK item and pam_winbind should use it. If you put the password pam_unix line twice into the config are you prompted 3 or 4 times for the password? If 3 times the problem is in pam_winbind either in the way the options are set or in the code. If 4 times, the problem is that pam_unix does not correctly set PAM_OLDAUTHTOK item. In the case where a password change is triggered *during* login, surely PAM_OLDAUTHTOK should come from the *actual* password that I successfully logged in with? I didn't authenticate with pam_unix; I authenticated with pam_winbind. Should *that* have set PAM_OLDAUTHTOK, when it returned PAM_NEW_AUTHTOK_REQD in the session stack? I changed /etc/pam.d/password-auth to read as follows: password requisite pam_pwquality.so try_first_pass retry=3 authtok_type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_winbind.so use_authtok password required pam_deny.so I'm still only asked for '(current) UNIX password' once. So that's three times as before — the password I use for the *auth*, then both pam_unix and pam_winbind asking me for an 'old' password during the *password* stack run. If I remove 'use_authtok' and 'try_first_pass' from the second pam_unix line, then I *do* get that '(current) UNIX password' question twice. We can perhaps eliminate pam_unix from the equation and treat it as a separate issue. If I remove *both* pam_unix lines from the above, my login experience with GDM now goes: username: dwoodhou password: letmein! change password [yes/no/maybe]: yes (current) NT password: ...GR YOU ALREADY GOT TOLD THIS! FWIW the experience with pam_unix is similar with passwd(8) although obviously I don't expect the PAM password stack to *know* my old password in advance in that case. I do expect to have to tell it once this time, but not *twice*: $ passwd Changing password for user dwoodhou. Changing password for dwoodhou. (current) UNIX password: Changing password for dwoodhou (current) NT password: There are two problems: 1. transferring the PAM_AUTHTOK from the auth step to PAM_OLDAUTHTOK in the password step is not easily possible. The PAM library actually actively clears the PAM_AUTHTOK value when the auth stack finishes. Of course there could be for example a module in the stack, that would save the password to PAM data and pull it out of there in tha password stack. But that would require configuration changes as well. Or we could change pam library to do that on its own but that would require consensual decision on PAM upstream whether this is desirable at all. 2. much more easily solvable problem is the third prompt from pam_winbind - it should pull the password from PAM_OLDAUTHTOK and it is apparently not doing it. Reassigning to samba for investigation of the problem 2. Note that although problem 1 is hard to solve "properly" for the reasons you describe, there's potentially scope for a winbind-specific solution. Firstly, pam_winbind does "squirrel away" the user's password to winbindd, so it isn't lost. There may be some way for us to handle it that way (although offering a generic way to prod winbindd to "change my password to <XXX>" which works forever after login is not a good idea, of course). Alternatively, pam_winbind does already store the fact that the password *needs* to be changed, in since it's discovered at auth time and needs to be reported in the account stack (cf. https://bugzilla.samba.org/show_bug.cgi?id=1524). So *maybe* it could also store the old authtok when it sets PAM_WINBIND_NEW_AUTHTOK_REQD_DURING_AUTH? This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |