Description of problem: I'm using GDM with the following in /etc/dconf/db/gdm.d/ [org/gnome/login-screen] disable-user-list=true as I have a lab of computers and don't need the students seeing each others accounts. When you type in your username and then press Next (or hit enter) it asks for your username again, except this time there's a Cancel option too. From here login works fine, but it's tripping up a lot of students (and myself) and exposing passwords where they are typing their passwords in plain text (because GDM is asking for the username a second time.) I'm using LDAP for use authentication in the lab, but the same thing happens even if I try to log in as a local user on the machine. Version-Release number of selected component (if applicable): gdm-3.10.0.1-1.fc20.x86_64 How reproducible: It doesn't always happen, but it certainly happens each time you try to log in for the first time and after each subsequent log out. If the login fails (bad password for example), then the asks for a single username. Steps to Reproduce: 1. Set up gdm to disable the user list 2. Restart system 3. Type in username and hit enter Actual results: GDM asks for the username again Expected results: GDM asks for the password. Additional info: I've set this as urgent as it is a security risk. Users logging in would normally expect to type their username once, so they end up typing their password as plain text.
I've been looking around for answers to this bug and have come upon this (which is apparently from bug #666330 but I'm not allowed to view that bug.) "The gdm greeter displays a list of all valid user accounts. That is not acceptable for an Enterprise Class OS. It is a significant security lapse that should have been corrected before GA." I'm guessing it's also no acceptable that a log in process should work in such a way that users inadvertently expose their passwords.
You're looking for bug #666220, which should be visible to all. But that doesn't add much, except for the suggestion to use this config option, and comments about what should be the default for RHEL.
Created attachment 895946 [details] Error log of failed login We observe the same behaviour (AD used for authentication). But only rarely, I had to reboot 5 times to get the log attached. After the last message, the login prompt appeared again, or more precisely: it was dimmed, then the login entered was removed and the field was accessible again. Usually, if you enter a login unknown to the system, the login process continues with asking for the password before reporting an error. I would expect a similar behavior here. It's unexpected to get a login field twice in succession.
My tests seem to reveal a consistent pattern: - Boot the machine, then when the login screen appears, type a username. It then goes correctly to Password. - Boot the machine and leave for a few minutes. The screen goes blank. Wiggle the mouse and the "screen shield" appears. Lift the shield. Type a username and press Enter. It then ignores what you typed and prompts for the username again. There does seem to be a strong connection between this bug and the screen shield. Unfortunately after extensive investigation I have failed to find a way to turn the shield off on the gdm login screen. (Incidentally the shield sometimes seems to appear at weird times - for example, immediately after logging out. But this behaviour is not consistent.)
I can confirm that it is strongly linked to the screen shield. Whenever it appears, I can be 100% sure I'll have to type my username twice.
This was also reported against gnome-shell at Bug 1073713.
I wanted to confirm that this bug also affects RHEL 7 and behaves in exactly the same manner.
Same problem : https://bugzilla.redhat.com/show_bug.cgi?id=1112548
And here : https://bugzilla.gnome.org/show_bug.cgi?id=729246
The patch seems to be here : https://bugzilla.gnome.org/attachment.cgi?id=278429
it seems you have to apply the patch to this file : /usr/share/gnome-shell/js/gdm/loginDialog.js
The patch not works for me : Fedora 20 x86_64 user list disabled with gdconf and gdm-3.10.0.1-1.fc20.x86_64
not gdconf -> dconf_update
[org/gnome/login-screen] disable-user-list=true
This appears to be related to an upstream bug here: https://bugzilla.gnome.org/show_bug.cgi?id=729246 There is a patch listed in that bug as a potential fix. Given the high likelihood of users entering their password in the user box (and consequently it being saved in plain text logs and sealed journal logs) I'd suggest this is an actual security issue and although 'unconfirmed' upstream I suggest that it's worth patching into Fedora 20 sooner rather than later. On a side note the patch is for loginDialog.js which is actually in gnome-shell rather than the gdm this has been reported against. Having applied the patch Jan Hacker provided in the upstream bug the username prompt is not reappearing.
This is still a problem as of gnome-shell-3.10.4-8.fc20.x86_64 which is the current version. There appears to be a fix that's available. This is a serious security issue (anytime passwords might be typed in plain text is). When will this patch be applied and an update released? I'm reassigning this to gnome-shell as it appears that it's not gdm but gnome-shell that needs to be patched and maybe this is why it's not being addressed.
Upstream have merged the patch - can this now be updated in F20+ so I can remove our override in puppet?
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 '20'. 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 20 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 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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.
On Fedora 22 this is still the case. uname -a gives: Linux 4.1.6-201.fc22.x86_64 #1 SMP Fri Sep 4 17:49:24 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux