Hello, Many thanks for the follow up but I think I've fixed it, or at least have a solution. The error return of 3 suggested that something bad was happening inside the shared library. As a trial I tried giving PAM the terminal name using pam_set_item(pamh,PAM_TTY,"/dev/tty0") and the problem went away and the program worked as expected. I then tried setting the TTY to an empty string pam_set_item(pamh,PAM_TTY,"") and my program still worked fine which begs the question should PAM expect to have a TTY and is the shared library walking off the end of a pointer if not supplied with one. I see no reason to have to supply a TTY name but I may be wrong ? Martin "Andrew Morgan" <morgan@transmeta.com> wrote in message 3A5F87B2.5309BE76@transmeta.com">news:3A5F87B2.5309BE76@transmeta.com... > Martin Waller wrote: > > > > Hello, > > > > I'm trying to write a small program that uses PAM to authenticate a user > > given a username and password. The program I have uses pam_start and > > pam_authenticate. What I'm finding on Linux is that pam_authenticate calls > > the conversation routine once for the password and always returns PAM error > > code 3. The same program works fine on a Sun machine and fine on an HP-UX > > machine and I can't see where I'm going wrong. It's almost as if PAM is not > > linked upto the /etc/passwd file which is the authentication mechanism we > > use. > > Can you tell if the module gets the password? What does > /var/log/messages say? > > > Should we expect PAM to work straight out of the box or is there something > > more that needs to be done ? > > Were any versions of PAM buggy ? > > What version are you using? > > Cheers > > Andrew > > > > _______________________________________________ > > Pam-list@redhat.com > https://listman.redhat.com/mailman/listinfo/pam-list
