PAM.CONF(5) claims: The module-path field specifies the name or full path of the module to call. If only the name is specified, the PAM library will search for it in the following locations: 1. /usr/lib 2. /usr/local/lib When I use auth required pam_ldap.so.1 no_warn try_first_pass instead of auth required /usr/local/lib/pam_ldap.so.1 no_warn try_first_pass I get following errors when system starts. Jun 18 10:24:17 lien login: in openpam_load_module(): no pam_ldap.so.1 found Jun 18 10:24:17 lien login: pam_start(): system error Jun 18 10:24:17 lien login: in openpam_load_module(): no pam_ldap.so.1 found Jun 18 10:24:17 lien login: pam_start(): system error Jun 18 10:24:17 lien login: in openpam_load_module(): no pam_ldap.so.1 found Jun 18 10:24:17 lien login: pam_start(): system error Jun 18 10:24:17 lien login: in openpam_load_module(): no pam_ldap.so.1 found Jun 18 10:24:17 lien login: pam_start(): system error Jun 18 10:24:17 lien init: getty repeating too quickly on port /dev/ttyv1, sleeping 30 secs This issue disallows me to log into as root. getent proved that LDAP itself works fine. /etc/nsswitch.conf: mrehak@lien:~$ cat /etc/nsswitch.conf group: files ldap hosts: files dns networks: files passwd: files ldap shells: files services: files protocols: files rpc: files I did freebsd-update fetch and install on June 4 and forgot to restart. Today I have found the machine in this state after reboot. As there was a PAM related change in 10.0-RELEASE-p4 I would guess there is the cause. In the evening I will confirm that the issue is really there. I will try the same on the second machine.
I am unable to reproduce this issue on my second machine (same release, patch level). I will try to flip this back again on the box where I have seen it to verify that.
Fix summary, notify possibly interested committer.
Can you ktrace a process trying to load a PAM policy which triggers the error, such as login(1) or su(1)? For instance (after editing /etc/pam.d/su): # env LD_UTRACE=1 ktrace su nobody then post the output of # kdump -tnu which will show vfs name lookups and run-time loader events. If you have two machines and it works on one but not the other, please post dumps from both.
I can confirm this issue with another PAM module: it is provided by the security/pam_fprint port. The module is installed at: /usr/local/lib/pam_fprint.so Adding it in /etc/pam.d/system without the path, as shown below, leads to immediate havoc: ... auth sufficient pam_fprint.so auth required pam_unix.so no_warn try_first_pass nullok ... No su to root: "su: pam_start: system error". No login after reboot: "login: in openpam_load_module(): no pam_fprint.so found" After adding the full path to /etc/pam.d/system in single-user mode errors disappear and I can use the fingerprint reader to log in. Tested as des@ required: # env LD_UTRACE=1 ktrace su nobody su: pam_start: system error # kdump -tnu 942 ktrace NAMI "/sbin/su" 942 ktrace NAMI "/bin/su" 942 ktrace NAMI "/usr/sbin/su" 942 ktrace NAMI "/usr/bin/su" 942 ktrace NAMI "/libexec/ld-elf.so.1" 942 su NAMI "/etc" 942 su NAMI "/etc/libmap.conf" 942 su NAMI "/etc/libmap.conf" 942 su NAMI "/usr" 942 su NAMI "/usr/local" 942 su NAMI "/usr/local/etc" 942 su NAMI "/usr/local/etc/libmap.d" 942 su NAMI "/var/run/ld-elf.so.hints" 942 su NAMI "/lib/libutil.so.9" 942 su NAMI "/lib/libutil.so.9" 942 su USER RTLD: loaded 0x800624400 @ 0x800822000 - 0x800a34fff (/lib/libutil.so.9) 942 su NAMI "/lib/libpam.so.5" 942 su NAMI "/usr/lib/libpam.so.5" 942 su NAMI "/usr/lib/libpam.so.5" 942 su USER RTLD: loaded 0x800624800 @ 0x800a35000 - 0x800c41fff (/usr/lib/libpam.so.5) 942 su NAMI "/lib/libbsm.so.3" 942 su NAMI "/usr/lib/libbsm.so.3" 942 su NAMI "/usr/lib/libbsm.so.3" 942 su USER RTLD: loaded 0x800624c00 @ 0x800c42000 - 0x800e5cfff (/usr/lib/libbsm.so.3) 942 su NAMI "/lib/libc.so.7" 942 su NAMI "/lib/libc.so.7" 942 su USER RTLD: loaded 0x800628000 @ 0x800e5d000 - 0x8011fffff (/lib/libc.so.7) 942 su USER RTLD: init 0x800e94fe8 for 0x800628000 (/lib/libc.so.7) 942 su NAMI "/etc/malloc.conf" 942 su USER RTLD: init 0x800c46aa8 for 0x800624c00 (/usr/lib/libbsm.so.3) 942 su USER RTLD: init 0x800a38220 for 0x800624800 (/usr/lib/libpam.so.5) 942 su USER RTLD: init 0x800826bb0 for 0x800624400 (/lib/libutil.so.9) 942 su USER RTLD: init 0x401708 for 0x800624000 (/usr/bin/su) 942 su NAMI "/etc/nsswitch.conf" 942 su NAMI "/etc/nsswitch.conf" 942 su USER dlopen(nss_compat.so.1, RTLD_LAZY) 942 su NAMI "/lib/nss_compat.so.1" 942 su NAMI "/usr/lib/nss_compat.so.1" 942 su NAMI "/usr/lib/compat/nss_compat.so.1" 942 su NAMI "/usr/local/lib/nss_compat.so.1" 942 su NAMI "/usr/local/lib/nss/nss_compat.so.1" 942 su NAMI "/usr/local/llvm35/lib/nss_compat.so.1" 942 su NAMI "/lib/nss_compat.so.1" 942 su NAMI "/usr/lib/nss_compat.so.1" 942 su USER 0x0 = dlopen(nss_compat.so.1) ref 0 942 su USER dlopen(nss_nis.so.1, RTLD_LAZY) 942 su NAMI "/lib/nss_nis.so.1" 942 su NAMI "/usr/lib/nss_nis.so.1" 942 su NAMI "/usr/lib/compat/nss_nis.so.1" 942 su NAMI "/usr/local/lib/nss_nis.so.1" 942 su NAMI "/usr/local/lib/nss/nss_nis.so.1" 942 su NAMI "/usr/local/llvm35/lib/nss_nis.so.1" 942 su NAMI "/lib/nss_nis.so.1" 942 su NAMI "/usr/lib/nss_nis.so.1" 942 su USER 0x0 = dlopen(nss_nis.so.1) ref 0 942 su USER dlopen(nss_files.so.1, RTLD_LAZY) 942 su NAMI "/lib/nss_files.so.1" 942 su NAMI "/usr/lib/nss_files.so.1" 942 su NAMI "/usr/lib/compat/nss_files.so.1" 942 su NAMI "/usr/local/lib/nss_files.so.1" 942 su NAMI "/usr/local/lib/nss/nss_files.so.1" 942 su NAMI "/usr/local/llvm35/lib/nss_files.so.1" 942 su NAMI "/lib/nss_files.so.1" 942 su NAMI "/usr/lib/nss_files.so.1" 942 su USER 0x0 = dlopen(nss_files.so.1) ref 0 942 su USER dlopen(nss_dns.so.1, RTLD_LAZY) 942 su NAMI "/lib/nss_dns.so.1" 942 su NAMI "/usr/lib/nss_dns.so.1" 942 su NAMI "/usr/lib/compat/nss_dns.so.1" 942 su NAMI "/usr/local/lib/nss_dns.so.1" 942 su NAMI "/usr/local/lib/nss/nss_dns.so.1" 942 su NAMI "/usr/local/llvm35/lib/nss_dns.so.1" 942 su NAMI "/lib/nss_dns.so.1" 942 su NAMI "/usr/lib/nss_dns.so.1" 942 su USER 0x0 = dlopen(nss_dns.so.1) ref 0 942 su USER dlopen(, RTLD_LAZY | RTLD_GLOBAL) 942 su USER 0x800624000 = dlopen() ref 1 942 su USER RTLD: dlsym(0x800624000, _nss_cache_cycle_prevention_function) 942 su USER RTLD: 0x0 = dlsym(0x800624000, _nss_cache_cycle_prevention_function) 942 su USER dlclose(0x800624000) (/usr/bin/su, 1) 942 su USER dlclose(0x800624000) finished 942 su NAMI "/etc/spwd.db" 942 su NAMI "/etc/nsswitch.conf" 942 su NAMI "/etc/spwd.db" 942 su NAMI "/etc/pam.d/su" 942 su NAMI "/usr/lib//pam_rootok.so.5" 942 su USER dlopen(, RTLD_NOW) 942 su USER RTLD: loaded 0x800628400 @ 0x801600000 - 0x801800fff () 942 su USER 0x800628400 = dlopen() ref 1 942 su USER RTLD: init 0x8016004f8 for 0x800628400 () 942 su USER RTLD: dlsym(0x800628400, _pam_module) 942 su USER RTLD: 0x0 = dlsym(0x800628400, _pam_module) 942 su USER RTLD: dlsym(0x800628400, pam_sm_authenticate) 942 su USER RTLD: 0x8016005f0 = dlsym(0x800628400, pam_sm_authenticate) 942 su USER RTLD: dlsym(0x800628400, pam_sm_setcred) 942 su USER RTLD: 0x801600660 = dlsym(0x800628400, pam_sm_setcred) 942 su USER RTLD: dlsym(0x800628400, pam_sm_acct_mgmt) 942 su USER RTLD: 0x0 = dlsym(0x800628400, pam_sm_acct_mgmt) 942 su USER RTLD: dlsym(0x800628400, pam_sm_open_session) 942 su USER RTLD: 0x0 = dlsym(0x800628400, pam_sm_open_session) 942 su USER RTLD: dlsym(0x800628400, pam_sm_close_session) 942 su USER RTLD: 0x0 = dlsym(0x800628400, pam_sm_close_session) 942 su USER RTLD: dlsym(0x800628400, pam_sm_chauthtok) 942 su USER RTLD: 0x0 = dlsym(0x800628400, pam_sm_chauthtok) 942 su NAMI "/usr/lib//pam_self.so.5" 942 su USER dlopen(, RTLD_NOW) 942 su USER RTLD: loaded 0x800628800 @ 0x801801000 - 0x801a01fff () 942 su USER 0x800628800 = dlopen() ref 1 942 su USER RTLD: init 0x801801580 for 0x800628800 () 942 su USER RTLD: dlsym(0x800628800, _pam_module) 942 su USER RTLD: 0x0 = dlsym(0x800628800, _pam_module) 942 su USER RTLD: dlsym(0x800628800, pam_sm_authenticate) 942 su USER RTLD: 0x8018016a0 = dlsym(0x800628800, pam_sm_authenticate) 942 su USER RTLD: dlsym(0x800628800, pam_sm_setcred) 942 su USER RTLD: 0x801801750 = dlsym(0x800628800, pam_sm_setcred) 942 su USER RTLD: dlsym(0x800628800, pam_sm_acct_mgmt) 942 su USER RTLD: 0x0 = dlsym(0x800628800, pam_sm_acct_mgmt) 942 su USER RTLD: dlsym(0x800628800, pam_sm_open_session) 942 su USER RTLD: 0x0 = dlsym(0x800628800, pam_sm_open_session) 942 su USER RTLD: dlsym(0x800628800, pam_sm_close_session) 942 su USER RTLD: 0x0 = dlsym(0x800628800, pam_sm_close_session) 942 su USER RTLD: dlsym(0x800628800, pam_sm_chauthtok) 942 su USER RTLD: 0x0 = dlsym(0x800628800, pam_sm_chauthtok) 942 su NAMI "/usr/lib//pam_group.so.5" 942 su USER dlopen(, RTLD_NOW) 942 su USER RTLD: loaded 0x800628c00 @ 0x801a02000 - 0x801c02fff () 942 su USER 0x800628c00 = dlopen() ref 1 942 su USER RTLD: init 0x801a02668 for 0x800628c00 () 942 su USER RTLD: dlsym(0x800628c00, _pam_module) 942 su USER RTLD: 0x0 = dlsym(0x800628c00, _pam_module) 942 su USER RTLD: dlsym(0x800628c00, pam_sm_authenticate) 942 su USER RTLD: 0x801a027a0 = dlsym(0x800628c00, pam_sm_authenticate) 942 su USER RTLD: dlsym(0x800628c00, pam_sm_setcred) 942 su USER RTLD: 0x801a029a0 = dlsym(0x800628c00, pam_sm_setcred) 942 su USER RTLD: dlsym(0x800628c00, pam_sm_acct_mgmt) 942 su USER RTLD: 0x801a029b0 = dlsym(0x800628c00, pam_sm_acct_mgmt) 942 su USER RTLD: dlsym(0x800628c00, pam_sm_open_session) 942 su USER RTLD: 0x0 = dlsym(0x800628c00, pam_sm_open_session) 942 su USER RTLD: dlsym(0x800628c00, pam_sm_close_session) 942 su USER RTLD: 0x0 = dlsym(0x800628c00, pam_sm_close_session) 942 su USER RTLD: dlsym(0x800628c00, pam_sm_chauthtok) 942 su USER RTLD: 0x0 = dlsym(0x800628c00, pam_sm_chauthtok) 942 su NAMI "/usr/lib//pam_fprint.so.5" 942 su NAMI "/usr/lib//pam_fprint.so" 942 su NAMI "/etc/localtime" 942 su NAMI "/etc/localtime" 942 su NAMI "/usr/share/zoneinfo/posixrules" 942 su NAMI "/var/run/logpriv" 942 su USER dlclose(0x800628c00) (, 1) 942 su USER RTLD: fini 0x801a029f8 for 0x800628c00 () 942 su USER RTLD: unloaded 0x800628c00 @ 0x801a02000 - 0x801c02fff () 942 su USER dlclose(0x800628c00) finished 942 su USER dlclose(0x800628800) (, 1) 942 su USER RTLD: fini 0x801801798 for 0x800628800 () 942 su USER RTLD: unloaded 0x800628800 @ 0x801801000 - 0x801a01fff () 942 su USER dlclose(0x800628800) finished 942 su USER dlclose(0x800628400) (, 1) 942 su USER RTLD: fini 0x8016006a8 for 0x800628400 () 942 su USER RTLD: unloaded 0x800628400 @ 0x801600000 - 0x801800fff () 942 su USER dlclose(0x800628400) finished 942 su USER RTLD: fini 0x403298 for 0x800624000 (/usr/bin/su) 942 su USER RTLD: fini 0x8008302e8 for 0x800624400 (/lib/libutil.so.9) 942 su USER RTLD: fini 0x800a3ed38 for 0x800624800 (/usr/lib/libpam.so.5) 942 su USER RTLD: fini 0x800c57758 for 0x800624c00 (/usr/lib/libbsm.so.3) 942 su USER RTLD: fini 0x800fa4dc8 for 0x800628000 (/lib/libc.so.7) I don’t know if it is significant, but we found above several lines showing erroneous paths, e.g.: /usr/lib//pam_fprint.so. Hope it helps, Juan
Juan, I traced your problem (which is not the same as Martin's) to an integration issue between OpenPAM and FreeBSD. I assume you run 11, which is *very important information* and should have been the first thing you mentioned in your comment. The man page documents what OpenPAM does out of the box, but FreeBSD compiles OpenPAM with CFLAGS which modify the module search path. This was unintentionally broken in 10 and fixed in 11 but never merged back. The issue is complicated, because "broken in 10" means 32-bit binaries won't be able to use PAM at all, whereas "fixed in 11" means OpenPAM won't search /usr/local/lib. I forgot to address this in the original submission: > I did freebsd-update fetch and install on June 4 and forgot to restart. Today I have found the machine in this state after reboot. As there was a PAM related change in 10.0-RELEASE-p4 I would guess there is the cause. That change was not relevant—it only addresses what happens if libpam fails to load the configuration, in openpam_configure.c. The code that searches for and loads modules is in openpam_dynamic.c. I honestly don't know why it doesn't work for you, and have no way of figuring it out unless you send me a trace as requested.
A commit references this bug: Author: des Date: Mon Sep 21 17:26:36 UTC 2015 New revision: 288070 URL: https://svnweb.freebsd.org/changeset/base/288070 Log: Restore the upstream (and documented) behavior of searching for modules both in /usr/lib and /usr/local/lib, thus simplifying the use of modules from ports, without breaking the compat32 case again. PR: 191151 MFC after: 3 weeks Changes: head/contrib/openpam/lib/libpam/openpam_constants.c head/lib/libpam/Makefile.inc head/lib/libpam/libpam/Makefile
(In reply to commit-hook from comment #6) > I assume you run 11, which is *very important information* > and should have been the first thing you mentioned in your comment. Sorry, I’m not used to submitting bug reports and forgot to check the targeted FreeBSD version. Yes, I use HEAD. > I honestly don't know why it doesn't work for you, > and have no way of figuring it out unless you send me a trace as requested. Sorry again, but I thought I had followed your instructions by sending the output of 'kdump -tnu'. How can I get that “trace” you request?
By the way, I’ve found a similar open bug: #176481
> Sorry again, but I thought I had followed your instructions by sending the > output of 'kdump -tnu'. How can I get that “trace” you request? That was for Martin, not you. I got everything I needed from you and fixed your issue in base r191151. By the way, since OpenPAM Nummularia (FreeBSD 9.3 and newer), you can also leave out .so from the module name.
*** Bug 176481 has been marked as a duplicate of this bug. ***
(In reply to Dag-Erling Smørgrav from comment #9) Thanks, I can confirm your patch resolved the issue, I can use the name of the module without the .so extension or the path.
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.