Bug 378201 - sigsegv when using libpam-passthrou-plugin and pamSecure FALSE
sigsegv when using libpam-passthrou-plugin and pamSecure FALSE
Status: CLOSED NEXTRELEASE
Product: 389
Classification: Community
Component: Server - Plugins (Show other bugs)
1.1.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Rich Megginson
Chandrasekar Kannan
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-12 11:28 EST by Giuseppe Paterno
Modified: 2015-01-04 18:29 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-25 16:02:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Strace of the sigsegv (27.16 KB, application/x-gzip)
2007-11-12 11:28 EST, Giuseppe Paterno
no flags Details

  None (edit)
Description Giuseppe Paterno 2007-11-12 11:28:43 EST
Name        : fedora-ds-base           
Version     : 1.1.0                        
Release     : 1.2.fc7                    

Hi! I was trying to setup libpam-passthrou, but I got a segmentation fault when
specifying pamSecure: FALSE. I specified FALSE because I wasn't able to
authenticate users with PAM. I use as a back-end pam_krb, below the config in
the dse.ldif of the instance:

-------------------------------------------------------------------------------
dn: cn=PAM Pass Through Auth,cn=plugins,cn=config
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject
objectClass: pamConfig
cn: PAM Pass Through Auth
nsslapd-pluginPath: libpam-passthru-plugin
nsslapd-pluginInitfunc: pam_passthruauth_init
nsslapd-pluginType: preoperation
nsslapd-pluginEnabled: on
nsslapd-pluginloadglobal: true
nsslapd-plugin-depends-on-type: database
pamMissingSuffix: ALLOW
pamExcludeSuffix: cn=config
pamIncludeSuffix: dc=garl,dc=lan
pamIDMapMethod: RDN
pamFallback: FALSE
pamSecure: FALSE
pamService: ldapserver
nsslapd-pluginId: pam_passthruauth
nsslapd-pluginVersion: 1.1.0b1
nsslapd-pluginVendor: Fedora Project
nsslapd-pluginDescription: PAM pass through authentication plugin
-------------------------------------------------------------------------------

pam file ldapserver as follows, copied from system-auth:

-------------------------------------------------------------------------------
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_krb5.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_krb5.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    sufficient    pam_krb5.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet
use_uid
session     required      pam_unix.so
session     optional      pam_krb5.so
-------------------------------------------------------------------------------

(note: I can login with krb)

In attach the strace in gzipped format.
The aim is to do a bind with an user ldap with a KRB backend.
Let me know if you need more.
Thanks.
Comment 1 Giuseppe Paterno 2007-11-12 11:28:43 EST
Created attachment 255401 [details]
Strace of the sigsegv
Comment 2 Rich Megginson 2007-11-12 12:09:14 EST
Can you also paste your /etc/nsswitch.conf?  It looks like you are using
nss_ldap somewhere along the way.  There is a big problem with using nss_ldap in
the directory server or admin server process - the mozldap libraries we use are
not binary compatible with the openldap ones.  So either nss_ldap is making an
ldap api call with the mozldap library, or the directory server is attempting to
use the openldap library.
Comment 3 Giuseppe Paterno 2007-11-13 04:08:44 EST
Indeed I'm using LDAP in nsswitch, as I've got the server configured also as a
client (testing FreeIPA).Below nsswitch.conf:

------------------------------------------------------------------------
passwd:     files ldap
shadow:     files ldap
group:      files ldap

#hosts:     db files nisplus nis dns
hosts:      files dns

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files

netgroup:   files ldap

publickey:  nisplus

automount:  files ldap
aliases:    files nisplus
------------------------------------------------------------------------

Your thoughts make sense to me, altough I do believe that libpam should use pam
framework that in turns makes the openldap call.....

My aim is to have the DS authenticate bind requests against kerberos. 
If you have some suggestions, feel free to contact me in private. Thanks.
Comment 4 Rich Megginson 2007-11-13 10:33:02 EST
> My aim is to have the DS authenticate bind requests against kerberos. 
> If you have some suggestions, feel free to contact me in private. Thanks.

You mean, have the DS authenticate simple bind (username/password) requests
against kerberos?  That's what the pam passthru plugin was designed for.  I know
it works if you do not use ldap in /etc/nsswitch.conf or in your pam stack. 
This is how Red Hat uses Red Hat Dir. Srv. internally.  Simo and I discussed the
pam_ldap/nss_ldap issue yesterday on IRC - he is trying to figure out how to
solve this problem for freeipa.  He may have some more info.
Comment 6 Rich Megginson 2008-02-27 22:54:43 EST
Is this still a problem?
Comment 7 Rich Megginson 2009-03-25 16:02:08 EDT
The core dump should be fixed in the next release of Fedora DS.  Please reopen if appropriate.

Note You need to log in before you can comment on or make changes to this bug.