Bug 1271377 - Corner case where sddm allows the login even if the provided password is wrong
Corner case where sddm allows the login even if the provided password is wrong
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
23
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
: 1268624 1268649 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-13 15:19 EDT by Giulio 'juliuxpigface'
Modified: 2015-10-14 03:21 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-14 03:21:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Giulio 'juliuxpigface' 2015-10-13 15:19:53 EDT
Description of problem:
I found what seems a corner case where sddm allows the login even if the provided password is (strictly speaking...) actually "wrong". This might not be a true bug, but *in my opinion* the behavior of sddm is not what an user expects.


Version-Release number of selected component (if applicable):
sddm-0.12.0-3.fc23.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Configure an user without password (with initial-setup, for example)
2. Boot Fedora 23 KDE
3. Type random characters on the password field

Actual results:
1. sddm should refuse the login (the real password is blank).

Expected results:
1. sddm allows the user to login, even if the password is wrong.

Additional info:
Since I encountered the same situation with lightdm (https://bugzilla.redhat.com/show_bug.cgi?id=1268649) and lxdm (https://bugzilla.redhat.com/show_bug.cgi?id=1268624) too, I'm starting to think that I'm wrong and this is an expected behavior.
Comment 1 Rex Dieter 2015-10-13 15:29:03 EDT
It probably is expected, and is handled at the PAM layer (which is why all login managers behave the same).
Comment 2 Giulio 'juliuxpigface' 2015-10-13 15:34:42 EDT
Hi Rex, thank you for the quick answer.

(In reply to Rex Dieter from comment #1)
> It probably is expected, and is handled at the PAM layer (which is why all
> login managers behave the same).

So... That's might be the reason why I encountered this while unlocking the screen too: filing another one report for it, seems useless, then.
Comment 3 Rex Dieter 2015-10-13 15:51:03 EDT
Reassigning to pam, for authoritative opinion on how blank passwords are expected to work.
Comment 4 Rex Dieter 2015-10-13 15:51:30 EDT
*** Bug 1268649 has been marked as a duplicate of this bug. ***
Comment 5 Rex Dieter 2015-10-13 15:51:45 EDT
*** Bug 1268624 has been marked as a duplicate of this bug. ***
Comment 6 Tomas Mraz 2015-10-14 03:21:38 EDT
Yes, it is an expected behavior. If the display manager actually asked for the password only in case the PAM library calls the conversation function it would not ask for the password at all in this case. So notabug, at least not on the PAM side.

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