GNOME Bugzilla – Bug 85785
GDM2 fails to authenticate users with shadow passwords
Last modified: 2002-07-09 17:56:11 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.
Eck. George, can you take a look at this when you return?
I can confirm this happening on Source Mage, for every user who has built gdm2 to use shadow.
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.
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.
Created attachment 9307 [details] Modified (and working) Source Mage BUILD script.
Created attachment 9358 [details] [review] patch to daemon/Makefile.in
Adding PATCH keyword
Tested the patch on my Slackware box, worked like a charm. great work!
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.
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).
actually dlopening sounds like more of a hack ...
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