After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 85785 - GDM2 fails to authenticate users with shadow passwords
GDM2 fails to authenticate users with shadow passwords
Status: RESOLVED FIXED
Product: gdm
Classification: Core
Component: general
2.4.0.x
Other Linux
: High major
: ---
Assigned To: GDM maintainers
Trevor Curtis
Depends on:
Blocks:
 
 
Reported: 2002-06-18 16:20 UTC by Sam Steele
Modified: 2002-07-09 17:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Modified (and working) Source Mage BUILD script. (831 bytes, text/x-shellscript)
2002-06-19 00:25 UTC, christopher_brien
  Details
patch to daemon/Makefile.in (354 bytes, patch)
2002-06-20 19:17 UTC, christopher_brien
none Details | Review

Description Sam Steele 2002-06-18 16:20:03 UTC
Attempting to use the root password to access the configurator or any
username / password pair to login to the system result in an invalid name /
password message and no users are able to login to the system.  GDM2 has
been compiled with the verify-shadow authentication method.  I have tried
rebuilding GDM2 on several different Slackware 8.1 systems, using the
shadow password suite version 4.0.3, and they all result in the same problem.
Comment 1 Luis Villa 2002-06-18 19:12:00 UTC
Eck. George, can you take a look at this when you return?
Comment 2 christopher_brien 2002-06-18 19:35:34 UTC
 I can confirm this happening on Source Mage, for every user who has 
built gdm2 to use shadow. 
Comment 3 christopher_brien 2002-06-18 22:18:28 UTC
It seems that when calling the crypt() function (in verify-shadow.c)  
to verify the password, it's using the DES algorithm instead of the  
GNU md5 algorithm. Which then gives the wrong encrypted password,  
and authentication fails.  
Comment 4 christopher_brien 2002-06-19 00:19:28 UTC
It seems to be that gdm is linked with both libcrypt.so.1 (which
provides the GNU MD5 crypt) as well as the library which provides the
DES crypt (I think it's libc.so.6 - I could be wrong). But libcrypt is
linked after the other library, so it will use the DES crypt.

I've fixed this in Source Mage by editing the Makefile with the
following sed command, after the ./configure stage.

sedit 's#$(LINK)#$(LINK) $(LIBS)#' daemon/Makefile

This causes libcrypt to be linked first.
Sorry, I don't know enough about auto[make|conf] to fix the
Makefile.[am|in], but at least I've found the actual problem.
Comment 5 christopher_brien 2002-06-19 00:25:25 UTC
Created attachment 9307 [details]
Modified (and working) Source Mage BUILD script.
Comment 6 christopher_brien 2002-06-20 19:17:22 UTC
Created attachment 9358 [details] [review]
patch to daemon/Makefile.in
Comment 7 Andrew Sobala 2002-06-21 19:03:41 UTC
Adding PATCH keyword
Comment 8 Sam Steele 2002-06-22 18:05:13 UTC
Tested the patch on my Slackware box, worked like a charm. great work!
Comment 9 George Lebl 2002-07-07 02:01:48 UTC
Hopefully fixing this in CVS.  I change the configure.in on line 273
and changed the LIBS="$LIBS -lcrypt" to LIBS="-lcrypt $LIBS".  Can
someone try this and confirm?  If this isn't working then please
reopen this bug.
Comment 10 christopher_brien 2002-07-07 22:08:35 UTC
Sorry, but that won't work. $(LIBS) resolves to only include  
"-lcrypt", so any reordering of what eventually consititutes $(LIBS)  
is futile. The compilation line is identical. 
  
Besides, this is a bit of a hack. It might be better to use dlopen  
and dlsym to find the crypt function (although I'm not sure about  
security issues here).  
Comment 11 George Lebl 2002-07-09 02:43:01 UTC
actually dlopening sounds like more of a hack ...

Comment 12 George Lebl 2002-07-09 17:56:11 UTC
I have a solution ready to be committed, it will be in 2.4.0.1,
basically we just need to add it to the LDFLAGS rather then to LDADD