[openFATE 305686] [beta1] gnome-screensaver does not respond to an expired password
Feature changed by: Marcus Meissner (msmeissn) Feature #305686, revision 20 Title: [beta1] gnome-screensaver does not respond to an expired password openSUSE-11.2: Rejected by Stefan Behlert (sbehlert) reject date: 2009-09-08 20:39:08 reject reason: too late for that. Priority Requester: Mandatory Projectmanager: Important Requested by: Guy Lunardi (glunardi) Description: Using novell-lum-2.2.0.11-0.1 1. Authenticate to eDir, 2. Wait until the desktop is locked with screensaver enabled 3. Expire the user's password 4. Attempt to enter user password to unlock the destkop 5. The screensaver just goes into thinking mode for about 30 seconds then re-prompts the user for the password. If I disable password expire then I am able to unlock the desktop. Am attaching the gnome-screensaver file from /etc/pam.d. Relations: - gnome-screensaver does not respond to an expired password (novell/bugzilla/id: 224690) https://bugzilla.novell.com/show_bug.cgi?id=224690 Discussion: #2: Stefan Behlert (sbehlert) (2009-08-31 11:09:17) Marcus, can you give me an opinion from a security point-of-view? For me that sounds like a correct behavior. I'm wondering how other OSes handle this. #3: Marcus Meissner (msmeissn) (2009-09-07 16:32:41) (reply to #2) I think the reporter means that GNOME screensaver should show a message about the expiredness instead of "nothing". This probagly needs to be implemented in gnome-screensaver. #4: Stefan Behlert (sbehlert) (2009-09-08 20:40:02) (reply to #3) Ah, ok, I had a different understanding, but you are right, a message would be good enough. Alex, could someone from your team look at that? #5: Alex Chun Yin Lau (allau) (2009-09-17 17:29:57) Lance, why don't you take a look and see how difficult to add this message in to the screensaver. #9: Wang Lance (lzwang) (2009-11-25 12:10:27) Hi * I found that this feature is related to security. GS implemented three methods for authorization in source level. They are forking a process to call /sbin/unix2_chkpwd, directly calling pam API, and directly accessing system password database. But only one of them can be compiled in GS finally. Currently in SLED the default method is using the unix2_chkpwd helper. * I also found that the function of this feature has been implemented in the method of directly calling pam API. And it is not possible to implement the feature by avoiding modifying the source of /sbin/unix2_chkpwd which is a part of the package pam. Beause the unix2_chkpwd returns nothing about the expired password. * So I made a rpm with the method of directly calling pam API. However it need to change the default configuration about GS in /etc/pam.d. I do not kown, if it is OK. * I think maybe we need security team to look this part. * And this is the URL of new packages https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stand... Thanks Lance Wang #10: Marcus Meissner (msmeissn) (2009-11-30 10:10:25) (reply to #9) He asked me directly... quoting: The feature I am working on need to change the default pam configration of +gnome-screensaver. In /etc/pam.d/gnome-screensaver the original settings are auth include common-auth account include common-account password include common-password session include common-session and the settings I changed to are auth required pam_env.so auth optional pam_gnome_keyring.so auth required pam_unix.so sha512 shadow nullok try_first_pass use_authok account include common-account password include common-password session include common-session + #11: Marcus Meissner (msmeissn) (2009-11-30 10:12:49) (reply to #10) + I do not think this will work. + common-auth is there for a reason, namely you can switch authentication + methods. YOu are overriding it to hard and fixed new method. also with + fixed password crypt method. + I do not see how this can change the timeout behaviour + I also do not know if gnome-screensaver is able to do that anyway due + to its simple method of chceking passwords. + Ludwig or Thorsten , any comment? -- openSUSE Feature: https://features.opensuse.org/305686
participants (1)
-
fate_noreply@suse.de