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 126.96.36.199,
basically we just need to add it to the LDFLAGS rather then to LDADD