Debian Bug report logs - #356187
libpam-ldap: pam_ldap.so is not stackable

version graph

Package: libpam-ldap; Maintainer for libpam-ldap is Richard A Nelson (Rick) <cowboy@debian.org>; Source for libpam-ldap is src:libpam-ldap.

Reported by: Michael Bramer <grisu@laptop.deb-support.de>

Date: Fri, 10 Mar 2006 09:48:05 UTC

Severity: normal

Found in version libpam-ldap/178-1sarge1

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Stephen Frost <sfrost@debian.org>:
Bug#356187; Package libpam-ldap. Full text and rfc822 format available.

Acknowledgement sent to Michael Bramer <grisu@laptop.deb-support.de>:
New Bug report received and forwarded. Copy sent to Stephen Frost <sfrost@debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Michael Bramer <grisu@laptop.deb-support.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: libpam-ldap: pam_ldap.so is not stackable
Date: Fri, 10 Mar 2006 10:37:23 +0100
Package: libpam-ldap
Version: 178-1sarge1
Severity: normal

Hello

I muß query two ldap serves for a new mail server. 

I set this for /etc/pam.d/pop:
  auth    sufficient    pam_ldap.so config=/etc/pam_ldap_1.conf
  auth    required      pam_ldap.so config=/etc/pam_ldap_2.conf try_first_pass

  account sufficient    pam_ldap.so config=/etc/pam_ldap_1.conf
  account required      pam_ldap.so config=/etc/pam_ldap_2.conf try_first_pass

and this don't work. 

If I use only one ldap-server, it works. With both servers, only the first
server work.

I debug pam_ldap and found the Problem. 

In pam_ldap.c the funktion _pam_ldap_get_session (l:2630) check if the cache
has old cached informations. If the name of the config-name is changed
(l:2662), the user_info is released. This work fine, but after this, the
funktion go back without rereading the config (l:2672).

with this hacky-patch, i resolve the problem:
  |--- pam_ldap.c.old      2006-03-10 09:15:21.000000000 +0100
  |+++ pam_ldap.c  2006-03-10 09:15:41.000000000 +0100
  |@@ -2669,7 +2669,7 @@
  | #if LDAP_SET_REBIND_PROC_ARGS < 3
  |       global_session = *psession;
  | #endif
  |-      return PAM_SUCCESS;
  |+      // return PAM_SUCCESS;
  |     }
  |
  |   *psession = NULL;

But this is not a real solution. With this the cached data are never used und
maybe we have now some pointer problems or so.

Can you reproduce the bug? Can you make a real fix?

Thanks for your work

Gruss Grisu
-- 
Michael Bramer  -- http://www.feuerwehr.kreuzau.de/wiki/
PGP: finger grisu@db.debian.org  -- Linux Sysadmin   -- Use Debian Linux
Jaja. Die Heisenbergsche Unschaerferelation soll nur die Rechenfehler
der Simulationshardware verdecken.
  -- lutz@iks-jena.de (Lutz Donnerhacke) ueber simulierte Realitaet



Information forwarded to debian-bugs-dist@lists.debian.org, Richard A Nelson (Rick) <cowboy@debian.org>:
Bug#356187; Package libpam-ldap. (Mon, 27 Aug 2012 16:51:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Brian Kroth <bpkroth@gmail.com>:
Extra info received and forwarded to list. Copy sent to Richard A Nelson (Rick) <cowboy@debian.org>. (Mon, 27 Aug 2012 16:51:06 GMT) Full text and rfc822 format available.

Message #10 received at 356187@bugs.debian.org (full text, mbox):

From: Brian Kroth <bpkroth@gmail.com>
To: 356187@bugs.debian.org
Subject: libpam-ldap: pam_ldap.so is not stackable
Date: Mon, 27 Aug 2012 11:47:21 -0500
[Message part 1 (text/plain, inline)]
I know this is years and years later, but we recently ran into this as 
well.

In our case, I'm not connecting to different servers, but we do want to 
stack different pam_filters.

The relevant bits from pam.d/common-account look like this:
account [success=1 default=ignore] pam_unix.so
account required pam_ldap.so config=/etc/pam_ldap.conf
account required pam_permit.so

For instance, we'd like to be able to stack our pam.d/sudo file (or 
whatever) like so, so that the stuff above is executed first, then the 
stuff below:

# Include the typical unix and ldap rules from common-account
@include common-account
# Then a subset of them that uses a different pam_filter in it's conf.
# Still skip ldap if unix auth succeeds:
account [success=1 default=ignore] pam_unix.so
account required pam_ldap.so config=/etc/pam_ldap.conf.sudo
account required pam_permit.so

The relevant difference in pam_ldap.conf's look like this:

# pam_ldap.conf
pam_filter acl=unix-server

# pam_ldap.conf.sudo
pam_filter acl=sudo


Now, why not just make an "&(...)" filter in a single pam_ldap.conf, you 
ask?  Well, we have at least a dozen different kinds of default 
pam_ldap.conf files for various service hosts (mail, labs, etc.), and we 
may wish to tack on extra requirements for multiple different services 
for each of these (eg: cron, sudo, etc.).  Combining all of those 
together with various other constraints could lead to hundreds of 
combinations.  So, we'd prefer to stack them, as pam intended :)

The trouble is that currently the second set is just ignored since pam 
caches the config file details.  From the pam_ldap.conf man page:

config=<path>
	Specifies that pam_ldap should use the configuration file in 
	path  instead  of  pam_ldap.conf  to retrieve  its  global 
	configuration. Configuring multiple instances of pam_ldap for 
	the same service with different configuration files is not 
	supported, because the  configuration  information is cached.

I've tested the attached hackish patch and it seems to correctly work 
around this issue by forcing a reload of the config when the previously 
cached value doesn't match.  I think it should also work for different 
ldap servers, though I haven't tested it.

I'd love to see something like this pulled in by Debian or even 
upstream.

Let me know if you have any questions.

Thanks,
Brian
[pam_ldap.c.allow_stacked_reuse_for_unique_ldap_filters_in_different_configs.diff (text/x-diff, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Richard A Nelson (Rick) <cowboy@debian.org>:
Bug#356187; Package libpam-ldap. (Tue, 28 Aug 2012 16:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Brian Kroth <bpkroth@gmail.com>:
Extra info received and forwarded to list. Copy sent to Richard A Nelson (Rick) <cowboy@debian.org>. (Tue, 28 Aug 2012 16:33:03 GMT) Full text and rfc822 format available.

Message #15 received at 356187@bugs.debian.org (full text, mbox):

From: Brian Kroth <bpkroth@gmail.com>
To: 356187@bugs.debian.org
Subject: related upstream bug
Date: Tue, 28 Aug 2012 11:31:48 -0500
[Message part 1 (text/plain, inline)]
This looks to also be related:
http://bugzilla.padl.com/show_bug.cgi?id=191
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Richard A Nelson (Rick) <cowboy@debian.org>:
Bug#356187; Package libpam-ldap. (Tue, 16 Oct 2012 06:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Johannes Knauf <johannes.knauf@physik.uni-erlangen.de>:
Extra info received and forwarded to list. Copy sent to Richard A Nelson (Rick) <cowboy@debian.org>. (Tue, 16 Oct 2012 06:21:03 GMT) Full text and rfc822 format available.

Message #20 received at 356187@bugs.debian.org (full text, mbox):

From: Johannes Knauf <johannes.knauf@physik.uni-erlangen.de>
To: 356187@bugs.debian.org
Subject: 2 ldap servers - possibly better solution
Date: Tue, 16 Oct 2012 08:10:59 +0200
If you are administrating at least 1 of the 2 LDAP servers, you can
use pass-through authentication as an alternative. It is described in
http://www.openldap.org/doc/admin24/security.html

Then, pam_ldap authenticates to LDAP server 1 only, which holds
information about all users. For local users on server 1 it holds a
hash, for remote users on server 2, it holds a string
{SASL}username@server2 instead of the hash. If a user from server 2
tries to bind against server 1, authentication is delegated to 
server 2.

A tutorial can be found in http://wiki.debian.org/LDAP/PAM



Information forwarded to debian-bugs-dist@lists.debian.org, Richard A Nelson (Rick) <cowboy@debian.org>:
Bug#356187; Package libpam-ldap. (Thu, 18 Oct 2012 17:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Brian Kroth <bpkroth@gmail.com>:
Extra info received and forwarded to list. Copy sent to Richard A Nelson (Rick) <cowboy@debian.org>. (Thu, 18 Oct 2012 17:36:03 GMT) Full text and rfc822 format available.

Message #25 received at 356187@bugs.debian.org (full text, mbox):

From: Brian Kroth <bpkroth@gmail.com>
To: Johannes Knauf <johannes.knauf@physik.uni-erlangen.de>
Cc: 356187@bugs.debian.org
Subject: Re: Bug#356187: 2 ldap servers - possibly better solution
Date: Thu, 18 Oct 2012 12:32:50 -0500
[Message part 1 (text/plain, inline)]
Johannes Knauf <johannes.knauf@physik.uni-erlangen.de> 2012-10-16 08:10:
> If you are administrating at least 1 of the 2 LDAP servers, you can
> use pass-through authentication as an alternative. It is described in
> http://www.openldap.org/doc/admin24/security.html
>
> Then, pam_ldap authenticates to LDAP server 1 only, which holds
> information about all users. For local users on server 1 it holds a
> hash, for remote users on server 2, it holds a string
> {SASL}username@server2 instead of the hash. If a user from server 2
> tries to bind against server 1, authentication is delegated to
> server 2.
>
> A tutorial can be found in http://wiki.debian.org/LDAP/PAM

In my case they aren't actually separate servers, so to set yet another 
pair up just to do this would be overly complex.

Brian
[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 00:32:42 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.