you'll need access to a set of pam libraries compiled
with debugging information (to be most useful)
are you trying to debug a pam-aware application or
a pam module? (not that it really matters all that much)
here's a make line i used to debug a pam module i was
playing around with:
pam_shadowd.so: pam_shadow.c
gcc -g -Wall -fPIC -c pam_shadow.c
gcc -shared -Xlinker -x -Xlinker -rpath -Xlinker . \
-o pam_shadowd.so pam_shadow.o -L. \
-lpamd -lpam_miscd
note the linker arguments, by leaving a copy of the pam libraries
compiled with debugging info (pamd, pam_miscd) in the same
directory as the module, the loader will load those instead
of the default ones. (i didn't want to put libraries with
debugging information in /lib)
I'm not sure this is the best way, but it worked well for me.
Any ideas from real pam hackers out there?
HTH,
-b
> -----Original Message-----
> From: m96 [mailto:m96@gmx.li]
> Sent: Friday, March 29, 2002 9:15 AM
> To: mailing-list - pam-list
> Subject: Re: debugging pam modules
>
>
> thanks for the reply.
>
> that's what i made until now. but what i tried (without success) was
> attach the process to gdb and try to follow it. for example
> starting xdm
> in gdb and locating the problem in pam (without using the logs on
> stderr) and backtracing it. that means it's impossible debug
> it with gdb
> since user changes new process executions are made.
>
> regards,
> m96.
>
