|
Home > Archive > Unix Programming > April 2006 > sigsegv with PAM on Suse 9.0
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
sigsegv with PAM on Suse 9.0
|
|
|
| Hello,
I have an application which is running without problems on Red Hat
9.0, Solaris Sparc and Solaris Intel. The program uses PAM to
authenticate user requests. I brought the application over to a Suse
machine and it gets a SIGSEGV in the pm_sm_authenticate (in
/lib/security/pam_unix2.so). I tried both the Red Hat binaries and also
compiling it on SUSE (with gcc) with the same results.
Our program is multi-threaded (kind of), I believe SUSE 9.0 uses
LinuxThreads (where Red Hat 9.0 uses NPTL) - I'm not sure if this is
part of the problem. By "kind of" multi-threaded I mean our application
starts up and the main thread starts a secondary thread and then goes to
sleep. The created thread will get a request (via HTTP) which will
contain a username and password. This is then passed into PAM, which is
where it SIGSEGV. I've stepped through the code and all the values
appear correct. I am in the process of writing a small stand-alone
application which I can use to duplicate (or not) the problem. But I was
hoping someone on this list might be able to provide any guidance (or if
you can point me to a better list to use).
Thanks in advance
-Jim
| |
| Frank Cusack 2006-04-27, 1:28 pm |
| On Thu, 27 Apr 2006 12:14:17 -0400 Jim <jim.marshall@wbemsolutions.com> wrote:
> Hello,
> I have an application which is running without problems on Red Hat
> 9.0, Solaris Sparc and Solaris Intel. The program uses PAM to
> authenticate user requests. I brought the application over to a Suse
> machine and it gets a SIGSEGV in the pm_sm_authenticate (in
> /lib/security/pam_unix2.so). I tried both the Red Hat binaries and also
> compiling it on SUSE (with gcc) with the same results.
>
> Our program is multi-threaded (kind of), I believe SUSE 9.0 uses
> LinuxThreads (where Red Hat 9.0 uses NPTL) - I'm not sure if this is
> part of the problem. By "kind of" multi-threaded I mean our application
> starts up and the main thread starts a secondary thread and then goes to
> sleep. The created thread will get a request (via HTTP) which will
> contain a username and password. This is then passed into PAM, which is
> where it SIGSEGV.
Is the authenticating thread creating a new pam handle (pam_start())?
PAM is only thread-safe if each thread has its own handle. stack
trace might be useful to see.
-frank
| |
|
| Frank Cusack wrote:
> On Thu, 27 Apr 2006 12:14:17 -0400 Jim <jim.marshall@wbemsolutions.com> wrote:
>
>
>
> Is the authenticating thread creating a new pam handle (pam_start())?
> PAM is only thread-safe if each thread has its own handle. stack
> trace might be useful to see.
>
> -frank
Yes the function in the thread calls pam_start. I have a function called
"MYLIB_authenticate" in this function I call pam_start which returns
PAM_SUCCESS. I then call pam_authenticate () which is when the sigsegv
happens. I do have a callback 'conversation' function but I never hit
the break point in it.
Here is the calls that are made:
pam_handle_t *pamh = NULL;
/* app_pam_data is defined as struct app_pam_data { const char* password; };
struct app_pam_data app_data = {NULL};
struct pam_conv pamconv = {NULL, NULL};
/* password is pass in to the function */
app_data.password = password;
pamconv.conv = login_conv;
pamconv.appdata_ptr = &app_data;
status = pam_start(PAM_SERVICE_NAME, user_or_role, &pamconv, &pamh);
if (status == PAM_SUCCESS)
{
/* crashes on the next line */
status = pam_authenticate(pamh, PAM_SILENT|PAM_DISALLOW_NULL_AUTHTOK);
if (status == PAM_SUCCESS)
{
/* check if the authenicated user is allowed to use machine */
status = pam_acct_mgmt(pamh, PAM_SILENT|PAM_DISALLOW_NULL_AUTHTOK);
The stack trace is not helpful as it only shows the one function:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 32771 (LWP 19411)]
0x40704e36 in pam_sm_authenticate () from /lib/security/pam_unix.so
(gdb) bt
#0 0x40704e36 in pam_sm_authenticate () from /lib/security/pam_unix.so
(gdb)
just in case it matters here is the system info:
Linux starfury 2.4.21-303-athlon #1 Tue Dec 6 12:24:00 UTC 2005 i686
athlon i386 GNU/Linux
| |
|
|
> ....
> just in case it matters here is the system info:
> Linux starfury 2.4.21-303-athlon #1 Tue Dec 6 12:24:00 UTC 2005 i686
> athlon i386 GNU/Linux
>
Ok looks like we might have figured this out. It seems as though in
our optimization efforts we reduced the thread stack size. Our
intention was to reduce the threads stack size to 0x80000, but we made a
typo and only made the thread stack size 0x20000. Increasing this to
0x80000 resolves the problem in our application.
I could not duplicate the problem in a simple test application, but I
doubt I was using much stack space, whereas our main app is using a lot
more.
So just to be specific, before creating the thread we did the following:
size_t stacksize = 0x20000; // changed this to 0x80000
....
pthread_attr_init(&attr);
pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
pthread_attr_setstacksize(&attr, stacksize);
pthread_create(&threadID, &attr, secondaryThread, (void*)&data))
....
Thanks for reading and helping!
|
|
|
|
|