Bug 132819

Summary:	Failed loading pam_ldap.so from PAM (installed from security/pam_ldap, on FreeBSD 7.1-RELEASE amd64)
Product:	Ports & Packages	Reporter:	Alexandr Sergeev <ales>
Component:	Individual Port(s)	Assignee:	Joe Marcus Clarke <marcus>
Status:	Closed FIXED
Severity:	Affects Only Me	CC:	alex_sergueev
Priority:	Normal
Version:	Latest
Hardware:	Any
OS:	Any

Description Alexandr Sergeev 2009-03-19 16:30:01 UTC

Hi!
We have a problem when loading pam_ldap.so unit.
In auth.log the following error gets:

Mar 19 17:58:15 host sshd[36442]: in openpam_load_module(): no /usr/local/lib/pam_ldap.so found
Mar 19 17:58:15 host sshd[36442]: fatal: PAM: initialisation failed

The path to the unit is specified correctly, the rights are sets correctly, the unit file type is right:

# pwd
/usr/local/lib
ls -l | grep pam
-r--r--r-- 1 root wheel 42584 Mar 18 11:44 pam_ldap.so
lrwxr-xr-x 1 root wheel 18 Mar 17 18:17 pam_mkhomedir.so -> pam_mkhomedir.so.2
-r--r--r-- 1 root wheel 9056 Mar 17 18:17 pam_mkhomedir.so.2
# file pam_ldap.so
pam_ldap.so: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), stripped

However, pam_mkhomedir.so from the same directory boots normally.
A fragment of /etc/pam.d/sshd:

# auth
auth sufficient pam_opie.so no_warn no_fake_prompts
auth requisite pam_opieaccess.so no_warn allow_local
auth sufficient pam_unix.so no_warn try_first_pass
auth required /usr/local/lib/pam_ldap.so

Change of parametres of call of the unit, condition type, does not influence result.

The unit move to /usr/lib and instructions in pam.d/sshd without path also does not help .

Units are installed from newest ports.

On other machine with same hardware configuration, but 32bit FreeBSD (i386 kernel), pam_ldap works correctly.

I will be very glad to hear your advices on problem elimination! Fast introduction of this service very important for us.
Use of 32bit system not allowed, because it not detect over 4GB RAM.

How-To-Repeat:
Try to use pam_ldap from PAM on FreeBSD 7.1-RELEASE amd64 with similar hardware configuration (Intel Xeon).

Comment 1 Edwin Groothuis freebsd_committer

2009-03-19 16:30:19 UTC

Responsible Changed
From-To: freebsd-ports-bugs->marcus

Over to maintainer (via the GNATS Auto Assign Tool)

Comment 2 alex_sergueev 2009-03-19 19:52:12 UTC

Good evening!
I give the additional information on a problem: Failure is observed only 
with service sshd (config /etc/pam.d/sshd, and also at inclusion from 
pam.d/sshd other profiles pam, containing this unit)
Other services (checked su and passwd) loads the unit normally, and work 
with it.
Kernel customisations do not influence a situation. I loaded old (GENERIC) 
kernel for check.
Settings of sshd (/etc/ssh/sshd_config) did not be customised.

With the best regards, Alexandr.

Comment 3 Joe Marcus Clarke freebsd_committer

2009-03-22 17:59:59 UTC

State Changed
From-To: open->feedback

Please capture a ktrace/kdump of sshd when trying to load pam_ldap.so.

Comment 4 Alexandr Sergeev 2009-03-24 16:41:18 UTC

Good evening!

The decision to pass on i386 for increase of reliability of system was accepted.
However, on i386 the problem has repeated.

New system version (7.1 updated to STABLE):
FreeBSD host.ripn.net 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Mon Mar 23 18:32:22 MSK 2009     ales@host.ripn.net:/usr/obj/usr/src/sys/CUSTOM  i386

ktrace, kdump:


   670 sshd     RET   select 1
   670 sshd     CALL  accept(0x4,0xbfbfe720,0xbfbfee7c)
   670 sshd     STRU  struct sockaddr { AF_INET, 195.19.26.183:2012 }
   670 sshd     RET   accept 5
   670 sshd     CALL  fcntl(0x5,F_GETFL,0)
   670 sshd     RET   fcntl 6
   670 sshd     CALL  fcntl(0x5,F_SETFL,O_RDWR)
   670 sshd     RET   fcntl 0
   670 sshd     CALL  pipe
   670 sshd     RET   pipe 6
   670 sshd     CALL  socketpair(PF_LOCAL,SOCK_STREAM,0,0xbfbfee70)
   670 sshd     RET   socketpair 0
   670 sshd     CALL  fork
   670 sshd     RET   fork 23570/0x5c12
   670 sshd     CALL  close(0x7)
   670 sshd     RET   close 0
   670 sshd     CALL  write(0x8,0xbfbfe657,0x5)
   670 sshd     GIO   fd 8 wrote 5 bytes
       0x0000 0000 00b7 00                                                                                    |.....|

   670 sshd     RET   write 5
   670 sshd     CALL  write(0x8,0x28530000,0xb6)
   670 sshd     GIO   fd 8 wrote 182 bytes
       0x0000 0000 00ae 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a50 726f 746f 636f  |...............................Protoco|
       0x0026 6c20 320a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  |l 2...................................|
       0x004c 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  |......................................|
       0x0072 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 5375 6273 7973 7465 6d09 7366 7470 092f 7573 722f  |..................Subsystem.sftp./usr/|
       0x0098 6c69 6265 7865 632f 7366 7470 2d73 6572 7665 720a 0a0a 0a0a 0a0a 0000 0000                      |libexec/sftp-server...........|

   670 sshd     RET   write 182/0xb6
   670 sshd     CALL  close(0x8)
   670 sshd     RET   close 0
   670 sshd     CALL  close(0x9)
   670 sshd     RET   close 0
   670 sshd     CALL  close(0x5)
   670 sshd     RET   close 0
   670 sshd     CALL  gettimeofday(0xbfbfe5fc,0)
   670 sshd     RET   gettimeofday 0
   670 sshd     CALL  getpid
   670 sshd     RET   getpid 670/0x29e
   670 sshd     CALL  open(0x2839d21f,O_RDONLY,<unused>0)
   670 sshd     NAMI  "/dev/urandom"
   670 sshd     RET   open 5
   670 sshd     CALL  read(0x5,0xbfbfe608,0x74)
   670 sshd     GIO   fd 5 read 116 bytes
       0x0000 5d12 b05c 237b 7352 8767 0ff0 5ede 09c5 7711 e4d9 6082 ce84 50b5 9a42 a47f c7cb 6dfb dfaa cae4  |]..\#{sR.g..^...w...`...P..B....m.....|
       0x0026 e767 5411 5366 b7f7 b6a7 4fa4 e8f2 a3bd 1a3e f133 20ef 767c 2cb3 63f4 f315 7e57 4ef2 ee2a f7cb  |.gT.Sf....O......>.3 .v|,.c...~WN..*..|
       0x004c 5dc2 0001 09d3 bd7d f2fc 63a4 3764 8dfa e181 946f e6b3 1bfd 164c 800c f62c 49db fa16 5d03 b73a  |]......}..c.7d.....o.....L...,I...]..:|
       0x0072 12b7                                                                                            |..|

   670 sshd     RET   read 116/0x74
   670 sshd     CALL  close(0x5)
   670 sshd     RET   close 0
   670 sshd     CALL  select(0x7,0x285090ac,0,0,0)
   670 sshd     RET   select 1
   670 sshd     CALL  close(0x6)
   670 sshd     RET   close 0
   670 sshd     CALL  select(0x7,0x285090ac,0,0,0)
   670 sshd     RET   select -1 errno 4 Interrupted system call
   670 sshd     PSIG  SIGCHLD caught handler=0x8050550 mask=0x0 code=0x0
   670 sshd     CALL  wait4(0xffffffff,0xbfbfe36c,WNOHANG,0)
   670 sshd     RET   wait4 23570/0x5c12
   670 sshd     CALL  wait4(0xffffffff,0xbfbfe36c,WNOHANG,0)
   670 sshd     RET   wait4 0
   670 sshd     CALL  sigaction(SIGCHLD,0,0xbfbfe30c)
   670 sshd     RET   sigaction 0
   670 sshd     CALL  sigreturn(0xbfbfe3a0)
   670 sshd     RET   sigreturn JUSTRETURN
   670 sshd     CALL  select(0x7,0x285090ac,0,0,0)


On Sun, Mar 22, 2009 at 06:00:31PM +0000, marcus@FreeBSD.org wrote:
> Synopsis: Failed loading pam_ldap.so from PAM (installed from security/pam_ldap, on FreeBSD 7.1-RELEASE amd64)
> 
> State-Changed-From-To: open->feedback
> State-Changed-By: marcus
> State-Changed-When: Sun Mar 22 17:59:59 UTC 2009
> State-Changed-Why: 
> Please capture a ktrace/kdump of sshd when trying to load pam_ldap.so.
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=132819

-- 
______________________________________________________________________

Alexandr D.Sergeev	MSK-IX & Russian Institute for Public Networks
E-mail: ales@ripn.net		Network Operational Center

Comment 5 Joe Marcus Clarke freebsd_committer

2009-03-24 17:03:30 UTC

Alexandr D. Sergeev wrote:
> Good evening!
> 
> The decision to pass on i386 for increase of reliability of system was accepted.
> However, on i386 the problem has repeated.
> 
> New system version (7.1 updated to STABLE):
> FreeBSD host.ripn.net 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Mon Mar 23 18:32:22 MSK 2009     ales@host.ripn.net:/usr/obj/usr/src/sys/CUSTOM  i386
> 
> ktrace, kdump:
> 
> 
>    670 sshd     RET   select 1
>    670 sshd     CALL  accept(0x4,0xbfbfe720,0xbfbfee7c)
>    670 sshd     STRU  struct sockaddr { AF_INET, 195.19.26.183:2012 }
>    670 sshd     RET   accept 5
>    670 sshd     CALL  fcntl(0x5,F_GETFL,0)
>    670 sshd     RET   fcntl 6
>    670 sshd     CALL  fcntl(0x5,F_SETFL,O_RDWR)
>    670 sshd     RET   fcntl 0
>    670 sshd     CALL  pipe
>    670 sshd     RET   pipe 6
>    670 sshd     CALL  socketpair(PF_LOCAL,SOCK_STREAM,0,0xbfbfee70)
>    670 sshd     RET   socketpair 0
>    670 sshd     CALL  fork
>    670 sshd     RET   fork 23570/0x5c12
>    670 sshd     CALL  close(0x7)
>    670 sshd     RET   close 0
>    670 sshd     CALL  write(0x8,0xbfbfe657,0x5)
>    670 sshd     GIO   fd 8 wrote 5 bytes
>        0x0000 0000 00b7 00                                                                                    |.....|
> 
>    670 sshd     RET   write 5
>    670 sshd     CALL  write(0x8,0x28530000,0xb6)
>    670 sshd     GIO   fd 8 wrote 182 bytes
>        0x0000 0000 00ae 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a50 726f 746f 636f  |...............................Protoco|
>        0x0026 6c20 320a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  |l 2...................................|
>        0x004c 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a  |......................................|
>        0x0072 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 5375 6273 7973 7465 6d09 7366 7470 092f 7573 722f  |..................Subsystem.sftp./usr/|
>        0x0098 6c69 6265 7865 632f 7366 7470 2d73 6572 7665 720a 0a0a 0a0a 0a0a 0000 0000                      |libexec/sftp-server...........|
> 
>    670 sshd     RET   write 182/0xb6
>    670 sshd     CALL  close(0x8)
>    670 sshd     RET   close 0
>    670 sshd     CALL  close(0x9)
>    670 sshd     RET   close 0
>    670 sshd     CALL  close(0x5)
>    670 sshd     RET   close 0
>    670 sshd     CALL  gettimeofday(0xbfbfe5fc,0)
>    670 sshd     RET   gettimeofday 0
>    670 sshd     CALL  getpid
>    670 sshd     RET   getpid 670/0x29e
>    670 sshd     CALL  open(0x2839d21f,O_RDONLY,<unused>0)
>    670 sshd     NAMI  "/dev/urandom"
>    670 sshd     RET   open 5
>    670 sshd     CALL  read(0x5,0xbfbfe608,0x74)
>    670 sshd     GIO   fd 5 read 116 bytes
>        0x0000 5d12 b05c 237b 7352 8767 0ff0 5ede 09c5 7711 e4d9 6082 ce84 50b5 9a42 a47f c7cb 6dfb dfaa cae4  |]..\#{sR.g..^...w...`...P..B....m.....|
>        0x0026 e767 5411 5366 b7f7 b6a7 4fa4 e8f2 a3bd 1a3e f133 20ef 767c 2cb3 63f4 f315 7e57 4ef2 ee2a f7cb  |.gT.Sf....O......>.3 .v|,.c...~WN..*..|
>        0x004c 5dc2 0001 09d3 bd7d f2fc 63a4 3764 8dfa e181 946f e6b3 1bfd 164c 800c f62c 49db fa16 5d03 b73a  |]......}..c.7d.....o.....L...,I...]..:|
>        0x0072 12b7                                                                                            |..|
> 
>    670 sshd     RET   read 116/0x74
>    670 sshd     CALL  close(0x5)
>    670 sshd     RET   close 0
>    670 sshd     CALL  select(0x7,0x285090ac,0,0,0)
>    670 sshd     RET   select 1
>    670 sshd     CALL  close(0x6)
>    670 sshd     RET   close 0
>    670 sshd     CALL  select(0x7,0x285090ac,0,0,0)
>    670 sshd     RET   select -1 errno 4 Interrupted system call
>    670 sshd     PSIG  SIGCHLD caught handler=0x8050550 mask=0x0 code=0x0
>    670 sshd     CALL  wait4(0xffffffff,0xbfbfe36c,WNOHANG,0)
>    670 sshd     RET   wait4 23570/0x5c12
>    670 sshd     CALL  wait4(0xffffffff,0xbfbfe36c,WNOHANG,0)
>    670 sshd     RET   wait4 0
>    670 sshd     CALL  sigaction(SIGCHLD,0,0xbfbfe30c)
>    670 sshd     RET   sigaction 0
>    670 sshd     CALL  sigreturn(0xbfbfe3a0)
>    670 sshd     RET   sigreturn JUSTRETURN
>    670 sshd     CALL  select(0x7,0x285090ac,0,0,0)

I don't see any indication that sshd is even trying to load pam_ldap.so.
 Make sure you run ktrace with -d -i to capture forks.

Joe

> 
> 
> On Sun, Mar 22, 2009 at 06:00:31PM +0000, marcus@FreeBSD.org wrote:
>> Synopsis: Failed loading pam_ldap.so from PAM (installed from security/pam_ldap, on FreeBSD 7.1-RELEASE amd64)
>>
>> State-Changed-From-To: open->feedback
>> State-Changed-By: marcus
>> State-Changed-When: Sun Mar 22 17:59:59 UTC 2009
>> State-Changed-Why: 
>> Please capture a ktrace/kdump of sshd when trying to load pam_ldap.so.
>>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=132819
> 


-- 
Joe Marcus Clarke
FreeBSD GNOME Team	::	gnome@FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome

Comment 6 Mark Linimon freebsd_committer

2009-03-26 10:57:51 UTC

State Changed
From-To: feedback->open

From misfiled email caught in spamtrap: 

Date: Wed, 25 Mar 2009 11:44:11 +0300

Comment 7 Mark Linimon 2009-03-26 11:04:14 UTC

----- Forwarded message from Mark Linimon <linimon@lonesome.com> -----

On Thu, Mar 26, 2009 at 10:59:42AM +0000, linimon@FreeBSD.org wrote:
> Diagnostics in http://people.freebsd.org/~linimon/kdump.out .  [bugmeister
> note: the dump was far too large to be suitable for the database]

oops: http://people.freebsd.org/~linimon/tmp/kdump.out .

mcl

----- End forwarded message -----

Comment 8 Alexandr Sergeev 2009-03-26 13:05:09 UTC

We have decided to refuse use pam_ldap in the introduced project,
 therefore promptness of the decision of a problem is noncritical.
The demand priority can be lowered.
Thanks for support!

______________________________________________________________________

Alexandr D.Sergeev	MSK-IX & Russian Institute for Public Networks
E-mail: ales@ripn.net		Network Operational Center

Comment 9 Joe Marcus Clarke freebsd_committer

2009-03-28 19:37:32 UTC

State Changed
From-To: open->feedback

Requested a rebuild of libpam with -DOPENPAM_DEBUG to get more details as 
to why the module load fails.

Comment 10 Joe Marcus Clarke freebsd_committer

2009-05-09 21:13:52 UTC

State Changed
From-To: feedback->closed

This was caused by linking OpenLDAP to the ports version of OpenSSL.  The 
pam_ldap module is only supported with OpenLDAP linked to the base 
OpenSSL.  Switching to base OpenSSL has been known to fix this for one 
user.