Bug 216816 - the gnome-screensaver will not unlock
Summary: the gnome-screensaver will not unlock
Status: RESOLVED FIXED
: 216951 (view as bug list)
Alias: None
Product: openSUSE 10.2
Classification: openSUSE
Component: Basesystem (show other bugs)
Version: Final
Hardware: Other SUSE Other
: P5 - None : Normal with 5 votes (vote)
Target Milestone: ---
Assignee: Ludwig Nussel
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-31 22:01 UTC by William Shackleford
Modified: 2007-01-17 13:18 UTC (History)
2 users (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description William Shackleford 2006-10-31 22:01:11 UTC
I have a system where users can log in but
if the screen locks it can never be unlocked.

I am not sure what has happened to the system 
but it is clearly testing for something very strange instead of the
password and failing, without giving the user or even adding
something to /var/log/messages to give any clue as to what the problem
is.

Each attempt to unlock a screen always produces two
entries in /var/log/messages one for the user and one for 
root. But it always fails whether you give the user passwd or
the root password. 

Oct 31 16:05:54 archimedes-304 unix2_chkpwd[12716]: pam_authenticate(gnome-screensaver, shackle): Authentication failure
Oct 31 16:05:59 archimedes-304 unix2_chkpwd[12717]: pam_authenticate(gnome-screensaver, root): Authentication failure

The same password works reliably when logging in 
every other way, (console, GDM, ssh etc)

/etc/pam.d/gnome-screensaver is unmodified. 
In fact 
rpm -V pam pam_modules gnome-screensaver
shows no modified files for any of these packages.
Comment 1 JP Rosevear 2006-11-01 18:47:55 UTC
*** Bug 216951 has been marked as a duplicate of this bug. ***
Comment 2 Robbert Eggermont 2006-12-13 11:04:30 UTC
I have the exact same problem with openSUSE 10.2 + (NIS+shadow) authentication + (gnome-screensaver/xlock):

Dec 12 11:27:44 client unix2_chkpwd[22851]: pam_authenticate(gnome-screensaver, user): Authentication failure
Dec 12 13:30:13 client unix2_chkpwd[28297]: pam_authenticate(xlock, user): Authentication failure

unix2_chkpwd needs root privileges to check NIS shadow.byname. The problem can be fixed by setting the suid bit for /sbin/unix2_chkpwd:
-rwsr-sr-x 1 root shadow 10112 Nov 25 20:14 /sbin/unix2_chkpwd
Comment 3 JP Rosevear 2006-12-13 12:24:56 UTC
gnome-screensaver is just following the pam rejection, re-assigning.
Comment 4 Michael Calmer 2006-12-13 15:17:22 UTC
On my 10.2 system I have:

$> l /sbin/unix2_chkpwd
-rwxr-sr-x 1 root shadow 10112 25. Nov 20:14 /sbin/unix2_chkpwd*

I the "s" on the group not sufficient?

pam-modules.spec says:

%attr(2755,root,shadow) /sbin/unix2_chkpwd

What are your permissions on this file?
Comment 5 Robbert Eggermont 2006-12-13 21:15:19 UTC
Sgid shadow is sufficient for reading /etc/shadow, but the keyword here is NIS:
the NIS server only accepts client port < 1024 (root!) for shadow.byname access.

With the install default (no suid root), unlocking fails always.
If I set suid, unlocking works perfectly (immidiately).
-rwsr-sr-x 1 root shadow 10112 Nov 25 20:14 /sbin/unix2_chkpwd

For reference, the KDE screensaver (unlocking this works out of the box) uses kcheckpass for authentication:
-rwsr-xr-x 1 root shadow 12K 2006-08-28 13:10 /opt/kde3/bin/kcheckpass*

According to http://ltp.sourceforge.net/docs/SLES-security-guide-EAL3.pdf:
"# set this to suid root (4755) if you’re running shadow via NIS:
/opt/kde3/bin/kcheckpass root.shadow 0755"

BTW: I encounter the same NIS+shadow authentication problem everywhere.
For example, for apache2 authentication I have to use mod_auth_external+pwauth suid root.

BTW2: I don't know if /sbin/unix_chkpwd is still used somewhere, if so that might require suid root as well.
Comment 6 Robbert Eggermont 2006-12-13 21:16:17 UTC
Sorry, forgot to change the status.
Comment 9 Michael Calmer 2007-01-04 15:30:08 UTC
set needinfo ...
Comment 10 Robbert Eggermont 2007-01-05 08:13:34 UTC
Can you please tell me what info you need? I answered your questions from comment #4 in comment #5.
Comment 11 Michael Calmer 2007-01-05 09:21:14 UTC
I need info from somebody else :-)
Comment 12 Robbert Eggermont 2007-01-05 09:32:01 UTC
I noticed, but I'm just curious what more info you need. ;-)
As I've encountered this shadow/NIS/SUID problem quite a few times in different places, I'ld like to keep informed about progress, solutions or anything related.
Comment 13 Michael Calmer 2007-01-05 09:58:27 UTC
Yes, this is because not every thinkable configuration can be supported by us per default. There are cases - especialy with suid bits - where we go a save way which should work for the most configurations , but not all. In these othere cases the administrator has to change our default. I you case now simply set the suid bit. It is needed in your case. 

The question we discuss here internaly is, if we want to change the default. 
Comment 14 Ludwig Nussel 2007-01-11 09:04:21 UTC
root:shadow 2755 is likely some historic artifact and wrong, unix2_chkpwd should be 4755. Needs to be fixed in the permissions package.
Comment 15 Ludwig Nussel 2007-01-17 13:18:32 UTC
fixed in permissions, pam, pam-modules and squid for 10.3