linuxconf problem solved (sort of)

["Jack Howarth" <howarth@bromo.med.uc.edu>]

Ulrich,
   Following a suggestion from the author of linuxconf, Jacque Gelinas, I
rebuilt my linuxconf binary so that it was linked against libpam (although
if dlopen is properly functioning that should be unnecessary). Sure enough
as soon as I did that password authentication started working again under
linuxconf. This isn't the first time I have seen this under the glibc 2.0.9x
releases. When I built python-1.5 which uses modules I saw similar failures
in the make check for python. You might look at that one as well as a test
case for these failures if you can't get linuxconf on your machine. I will
let you know if this solves the problems we see on intel as well. Keep in
mind we are building with egcs_1_1_branch as well. Below is the message
Jacques sent me which you might find interesting...

------------------------------------------------------------------------
On Thu, 29 Oct 1998, Jack Howarth wrote:

> Jacques,
>    You might want to set up an Intel Linux machine on glibc 2.0.99 or newer
> (these are available as source tarballs on alpha.gnu.org in /pub/gnu)
> soon. I have had verification that the linuxconf password authentication
> failures are cross-platform and apply to Intel linux as well. In other
> words at this point unless it is fixed linuxconf will break under glibc 2.1.
>                             Jack
> ps perhaps this might be useful. On my linuxppc machine running linux 2.1.126
> and glibc 2.0.99 I find the following in my /var/log/messages file everytime
> I attempt to change a password under linuxconf....
>
> Oct 29 19:14:17 dilbert pam[556]: unable to dlopen(/lib/security/pam_pwdb.so)
> Oct 29 19:14:17 dilbert pam[556]: [dlerror: /lib/security/pam_pwdb.so: undefin
ed
>  symbol: pam_get_item]  
> Oct 29 19:14:17 dilbert pam[556]: adding faulty module: /lib/security/pam_pwdb
.s
> o
> Oct 29 19:14:17 dilbert pam[556]: unable to dlopen(/lib/security/pam_cracklib.
so
> )
> Oct 29 19:14:17 dilbert pam[556]: [dlerror: /lib/security/pam_cracklib.so: und
ef
> ined symbol: pam_get_item]
> Oct 29 19:14:17 dilbert pam[556]: adding faulty module: /lib/security/pam_crac
kl
> ib.so

It certainly explain it all. If linuxconf can't load a dll for pam, it can
authenticate or change password.

I know little about pam, but there is one thing specific to linuxconf.
Linuxconf in itself, it not linked with libpam. The redhat module, itself
a dll load on the fly at linuxconf startup, is linked with /lib/libpam.so.
The symbol "pam_get_item" is part of this later so object.

So it should be found. Check on you system   

        nm /lib/libpam.so | grep pam_get_item

I guess it is there. Now the trick is that linuxconf is loading the redhat
module with the RTLD_GLOBAL option, which means that the symbols in the
loaded object as well as dependant libraries will be made visible to all
other dlopen'ed object. this means that when you dlopen the pam_pwdb.so
module, it will happily find pam_get_item.

So I guess that dlopen is broken in later glibc version, or that the api
have changed a bit and linuxconf is miss-using it. The modules in
linuxconf are loaded in misc/modules.cc. A big comment there explain the
usage of the GLOBAL flag.

One possible work-around (in the mean time) would be to link linuxconf   
with the -lpam option. This might solve the problem. If it does, it proves
that the problem is related to dlopen: Either a bug or the way I am using
it.

Keep me posted!  

> The really weird bit is that passwd which is linked dynamically to libpam.so
> and libpam_misc.so has no problems changing passwords. Likewise login has
> no problems authenticating users. Oh I am currently using pam-0.64 but see
> the same for pam-0.65.
>
> --
> ------------------------------------------------------------------------------
> Jack W. Howarth, Ph.D.                                     231 Bethesda Avenue
> NMR Facility Director                              Cincinnati, Ohio 45267-0524
> Dept. of Molecular Genetics                              phone: (513) 558-4420
> Univ. of Cincinnati College of Medicine                    fax: (513) 558-8474
>

--------------------------
Jacques Gelinas
jack@solucorp.qc.ca  
-------------------------------------------------------------------------------

-- 
------------------------------------------------------------------------------
Jack W. Howarth, Ph.D.                                     231 Bethesda Avenue
NMR Facility Director                              Cincinnati, Ohio 45267-0524
Dept. of Molecular Genetics                              phone: (513) 558-4420
Univ. of Cincinnati College of Medicine                    fax: (513) 558-8474