Merge lp:~mterry/unity8/dismiss-old-pam-prompts into lp:unity8
Status: | Merged |
---|---|
Approved by: | Michael Terry |
Approved revision: | 1180 |
Merged at revision: | 1192 |
Proposed branch: | lp:~mterry/unity8/dismiss-old-pam-prompts |
Merge into: | lp:unity8 |
Diff against target: |
153 lines (+43/-15) 2 files modified
qml/Greeter/GreeterContent.qml (+0/-1) tests/mocks/LightDM/demo/GreeterPrivate.cpp (+43/-14) |
To merge this branch: | bzr merge lp:~mterry/unity8/dismiss-old-pam-prompts |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Michał Sawicz | Approve | ||
PS Jenkins bot (community) | continuous-integration | Approve | |
Stephen M. Webb (community) | Approve | ||
Review via email: mp+231363@code.launchpad.net |
Commit message
Allow logging into a desktop or tablet session again, by properly dismissing old PAM conversations. (LP: #1350878)
In a desktop or tablet, we were accidentally starting two PAM conversations in sequence on startup. Which is a small bug; it shouldn't normally be a problem, since each new PAM conversation should kill the old one.
But the way we were killing the old one was subject to a thread race condition. See, a PAM conversation thread won't exit until all its prompts are answered. And what we do when we kill a PAM conversation is to answer all prompts with empty strings.
But it's possible that when we want to kill a PAM conversation that it hasn't actually gotten to the point of prompting us yet. And when those prompts do come through, we were treating them as prompts for the new PAM conversation.
So I've changed the PAM conversation logic to include a pam_handle and compare the handle with the current handle when being prompted. If it's an old handle, we just dismiss the prompt with an empty string response.
Oh, and I fixed the bug that caused two prompts on startup in the first place. (But we still need the above logic anyway, for when you switch users quickly.)
Description of the change
Allow logging into a desktop or tablet session again, by properly dismissing old PAM conversations. (LP: #1350878)
In a desktop or tablet, we were accidentally starting two PAM conversations in sequence on startup. Which is a small bug; it shouldn't normally be a problem, since each new PAM conversation should kill the old one.
But the way we were killing the old one was subject to a thread race condition. See, a PAM conversation thread won't exit until all its prompts are answered. And what we do when we kill a PAM conversation is to answer all prompts with empty strings.
But it's possible that when we want to kill a PAM conversation that it hasn't actually gotten to the point of prompting us yet. And when those prompts do come through, we were treating them as prompts for the new PAM conversation.
So I've changed the PAM conversation logic to include a pam_handle and compare the handle with the current handle when being prompted. If it's an old handle, we just dismiss the prompt with an empty string response.
Oh, and I fixed the bug that caused two prompts on startup in the first place. (But we still need the above logic anyway, for when you switch users quickly.)
== Checklist ==
* Are there any related MPs required for this MP to build/function as expected? Please list.
- No
* Did you perform an exploratory manual test run of your code change and any related functionality?
- Yes
* Did you make sure that your branch does not contain spurious tags?
- Yes
* If you changed the packaging (debian), did you subscribe the ubuntu-unity team to this MP?
- NA
* If you changed the UI, has there been a design review?
- NA
To test this, you can edit qml/Shell.qml to set "tablet: true" and then run "./run.sh --lightdm=demo -f" and try to log in with your desktop password.
Or you can install a unity8 desktop session and try to log into unity8. Or install Touch on a tablet and set a password.