[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: calling pam_sm_open_session



It figures:  the one time I want a core dump, I can't get one.
I tried both of Michael's suggestions (see #1 below) and neither
produced a core file.  I'm guessing the problem isn't with login.

I'm going to start compiling everything I can think of with
whatever debug options I can find.  In the mean time, can
anyone tell me what the "debug" on the /etc/pam.d/* files
does?  Am I supposed to get error/debug messages somewhere?
Anywhere in particular?  I can't see where that's giving me
anything.

Thanks for any and all ideas,
Kelli

-----Original Message-----
From: mjt@corpit.ru [mailto:mjt@corpit.ru]On Behalf Of Michael Ju.
Tokarev
Sent: Monday, September 25, 2000 12:35 PM
To: Kelli Wolfe
Cc: pam-list@redhat.com
Subject: Re: calling pam_sm_open_session


Kelli Wolfe wrote:
>
> Hello  Michael,
>
> Thank you for your offer of assistance, I'm in need:  that trace file
> is huge.

I told you about that.  But doesn't matter.

> I've attached it.  This is from the machine I'm trying to telnet into.
> There are a few things in this file that I'm unsure about.

> First, there's a 1000+ close(xxxx)  .....  (Bad file descriptor) messages.
This is normal.  Some application (that should be login) tries to close
all possible opened files (should be 1024-3 calls).  The simplest way of
that is just close 'em.

> Next there are several "Connection refused" messages, I'm not sure
> if they have anything to do here or not.

Probably not -- I can guess that the libc tried to connect to local
nscd (name service cache daemon); if it isn't running, libc will
fallback
to do the work itself.

> And lastly, there is a  "--- SIGSEGV (Segmentation fault) ---".

And most interesting really.  Unfortunately, this is what I expected
to see.  My guess was that (pamified) login (or one of pam modules,
or pam itself) just have trouble/bug somewhere that caused SISSEGV or
something similar to occur.  I was just not shure about that, as
telnetd exits with 1 (according to your logs), but that's normal.

Oh, ma, just some trivial bug/typo somewhere...  But this is from
things that are very hard to investigate remotely....

>   ------------------------------------------------------------------------
>                  Name: trc.tar.gz
>    trc.tar.gz    Type: Unix Tape Archive (application/x-tar)
>              Encoding: base64
>                  Size: 17143 bytes

Unfortunately (second time in this letter) I can't read this file:

 $ gzip -t trc.tar.gz
 gzip: trc.tar.gz: invalid compressed data--format violated
 $ _

And the file really looks "strange" at least.  I guess that your
"Microsoft Outlook 8.5, Build 4.71.2377.0" just screwed it up...

You can resend it (maybe using some real mailer instead), but I
think that it is not necessary anymore.  We need to find where
that sigsegv occured, and strace really can't help here.
Unfortunately (3rd time!!!) RedHat strips all binaries, so it
is not really possible to find where problem occurs.

As I guess, you are not a "unix guru" (or at least not a "unix
programmer guru").  But still can suggest you to do the following.

1. Enable (temporary) core dumping from your daemons (redhat by
   default forbids cores from daemons).  You can enable that two
   ways -- commenting out a line with 'ulimit -c 0' in /etc/rc.d/
   /init.d/functions (if I remember correctly), or replacing
   your login by little wrapper (but be very careful, and check
   that 'linux single' lilo command works before doing this):
     rename /bin/login to /bin/login.save
     create /bin/login with the following contents:
       #! /bin/sh
       ulimit -c 100000
       exec /bin/login.save $*
     and make it executable (chmod +x /bin/login)

2. Try to login again.  You should get core now, probably in /.
   Use 'gdb /bin/login /core' and look if it can tell you
   something useful (use "bt" command).  Information needed is
   a name of a module (most important) and function/linenumber of
   a place where that sigsegv occured.

3. If that does not shows anything, you need to recompile some
   packages/libraries used so that them have debugging info.
   And repeat step 2.

All of that is a work for package maintainers/authors (esp. if
user have no big expirience with all that stuff).  But problem
is that we can't tell _what_ package is in bad.  It is definitely
not telnet/telnetd.  It may be login, pam or one of pam modules.

Also, try asking other people -- e.g. behind pam_ldap and/or
login.

Or your can ask someone with programming expirience near you
to help you to do so.

I CC'd this message back to pam-list.

Regards,
 Michael.





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []