Re: pam_smbpass.so
On 02/18/2016 02:49 AM, Joe Pfeiffer wrote: > Christian Seiler <christ...@iwakd.de> writes: >> Just a hunch: do you run dovecot chroot'ed? If so, then it is most >> likely the case that the specific PAM module is not available within >> the chroot and that's why it produces that message. > > No, it isn't chrooted -- if it were, I'd expect the other pam modules to > give the same issues (for that matter, I'd expect it to not be able to > find pam.d!). So I just looked a bit at the PAM source code and found the following: 1. the message you see is generated from libpam/pam_handlers.c [1] from within the function _pam_load_module, using the mod_path argument passed to that function (which is not modified) 2. the function _pam_load_module is only called from _pam_add_handler, which calls it in two cases [2]: a. module name starts with a /, then it uses that directly b. module name doesn't start with a /, then it prepends DEFAULT_MODULE_PATH In Debian, DEFAULT_MODULE_PATH is /lib//security (set via debian/rules --libdir=/lib/ for dh_auto_configure [3], then used by configure.in as the default argument for --enable-securedir if that's not specified [4], which it isn't in debian/rules, and then used my Makefile.am to specify the variable to the C source [5]). [1] http://sources.debian.net/src/pam/1.1.8-3.2/libpam/pam_handlers.c/#L705 [2] http://sources.debian.net/src/pam/1.1.8-3.2/libpam/pam_handlers.c/#L760 [3] http://sources.debian.net/src/pam/1.1.8-3.2/debian/rules/#L30 [4] http://sources.debian.net/src/pam/1.1.8-3.2/configure.in/#L274 [5] http://sources.debian.net/src/pam/1.1.8-3.2/libpam/Makefile.am/#L5 If I look at your configuration file, we clearly have > # and here are more per-package modules (the "Additional" block) > authoptionalpam_mount.so > authoptional pam_smbpass.so migrate that the pam_smbpass.so is a relative path, so the code path 2(b) should be taken, so the error you see shouldn't appear. This is _really_ weird, especially since (as you said) the other modules should also be affected... I'm drawing a blank, sorry. Other than stracing the dovecot auth process hand hoping you find something in the (presumeably huge) log of that, I don't think I have any idea on how to debug that. Sorry. Regards, Christian signature.asc Description: OpenPGP digital signature
Re: pam_smbpass.so
Sven Hartge <s...@svenhartge.de> writes: > Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote: > >> I'm seeing a large number of entries in my /var/log/syslog that look >> like this: > >> Feb 16 09:07:31 snowball auth: PAM unable to dlopen(pam_smbpass.so): >> /lib/security/pam_smbpass.so: cannot open shared object file: No >> such file or directory >> Feb 16 09:07:31 snowball auth: PAM adding faulty module: pam_smbpass.so > >> So... any idea what's going on here, and more importantly how to fix >> it? I also see consistently that this is a harmless message, but it >> bugs me... > > Do a > > rgrep smbpass /etc/pam.d > > and see, if you have an old config file there which references > pam_smbpass.so via absolute path. This can cause this error. snowball:606$ rgrep smbpass /etc/pam.d /etc/pam.d/common-password:password optional pam_smbpass.so nullok use_authtok use_first_pass /etc/pam.d/common-auth:auth optionalpam_smbpass.so migrate > Odds are, you can just remove the old config file and purge the package > you installed, because you don't need it.
Re: pam_smbpass.so
Christian Seiler <christ...@iwakd.de> writes: > Hi, > > On 02/17/2016 05:11 PM, Joe Pfeiffer wrote: >> Christian Seiler writes: >>> [Suggesting journalctl -o verbose to debug this] >> I'm running a current Debian testing installation, and journal is >> enabled. >> >> It turns out it's only coming from /usr/lib/dovecot/auth. What's >> weird is in /etc/pam.d/, the only files using the module are >> common-auth and common-password, so I'd expect to see the error coming >> either every time someone authenticates through anything, or any time >> someone changes their password, and I'm not seeing either of those >> cases -- just dovecot. > > Just a hunch: do you run dovecot chroot'ed? If so, then it is most > likely the case that the specific PAM module is not available within > the chroot and that's why it produces that message. No, it isn't chrooted -- if it were, I'd expect the other pam modules to give the same issues (for that matter, I'd expect it to not be able to find pam.d!). > If that's not the case: what's the contents of /etc/pam.d/dovecot? > And /etc/pam.d/common-auth? /etc/pam.d/dovecot: #%PAM-1.0 @include common-auth @include common-account @include common-session /etc/pam.d/common-auth: # # /etc/pam.d/common-auth - authentication settings common to all services # # This file is included from other service-specific PAM config files, # and should contain a list of the authentication modules that define # the central authentication scheme for use on the system # (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the # traditional Unix authentication mechanisms. # # As of pam 1.0.1-6, this file is managed by pam-auth-update by default. # To take advantage of this, it is recommended that you configure any # local modules either before or after the default block, and use # pam-auth-update to manage selection of other modules. See # pam-auth-update(8) for details. # here are the per-package modules (the "Primary" block) authrequiredpam_abl.so config=/etc/security/pam_abl.conf auth[success=1 default=ignore] pam_unix.so nullok_secure try_first_pass # here's the fallback if no module succeeds authrequisite pam_deny.so # prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around authrequiredpam_permit.so # and here are more per-package modules (the "Additional" block) authoptionalpam_mount.so authoptionalpam_smbpass.so migrate authoptional pam_cap.so # end of pam-auth-update config (note the line authoptionalpam_smbpass.so migrate is added when libpam-smbpass is installed)
Re: pam_smbpass.so
Hi, On 02/17/2016 05:11 PM, Joe Pfeiffer wrote: > Christian Seiler writes: >> [Suggesting journalctl -o verbose to debug this] > I'm running a current Debian testing installation, and journal is > enabled. > > It turns out it's only coming from /usr/lib/dovecot/auth. What's > weird is in /etc/pam.d/, the only files using the module are > common-auth and common-password, so I'd expect to see the error coming > either every time someone authenticates through anything, or any time > someone changes their password, and I'm not seeing either of those > cases -- just dovecot. Just a hunch: do you run dovecot chroot'ed? If so, then it is most likely the case that the specific PAM module is not available within the chroot and that's why it produces that message. If that's not the case: what's the contents of /etc/pam.d/dovecot? And /etc/pam.d/common-auth? Regards, Christian signature.asc Description: OpenPGP digital signature
Re: pam_smbpass.so
Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote: > I'm seeing a large number of entries in my /var/log/syslog that look > like this: > Feb 16 09:07:31 snowball auth: PAM unable to dlopen(pam_smbpass.so): > /lib/security/pam_smbpass.so: cannot open shared object file: No such file or > directory > Feb 16 09:07:31 snowball auth: PAM adding faulty module: pam_smbpass.so > So... any idea what's going on here, and more importantly how to fix > it? I also see consistently that this is a harmless message, but it > bugs me... Do a rgrep smbpass /etc/pam.d and see, if you have an old config file there which references pam_smbpass.so via absolute path. This can cause this error. Odds are, you can just remove the old config file and purge the package you installed, because you don't need it. Grüße, S° -- Sigmentation fault. Core dumped.
pam_smbpass.so
I'm seeing a large number of entries in my /var/log/syslog that look like this: Feb 16 09:07:31 snowball auth: PAM unable to dlopen(pam_smbpass.so): /lib/security/pam_smbpass.so: cannot open shared object file: No such file or directory Feb 16 09:07:31 snowball auth: PAM adding faulty module: pam_smbpass.so Googling the error mesage, I see lots of very old bug reports (mainly 2008 timeframe, though a few are as recent as 2012 -- still pretty old) that look like this ubuntu forum thread: http://ubuntuforums.org/showthread.php?t=770724 but nothing recent. The fix in almost all those cases seems to have been to install libpam-smbpass (which makes sense, since that's where pam_smbpass.so lives). I have that package installed, so I have /lib/x86_64-linux-gnu/security/pam_smbpass.so So... this is, of course, not the directory that's being reported as the location of the missing file, however PAM is supposed to search /lib/security/ and /lib/x86_64-linux-gnu/security for modules. I've tried putting a symbolic link from the real file to /lib/security/pam_smbpass.so, which only gives me a raft of different error messages having to do with failed page mappings. I don't have any i386 PAM modules (nor libpam0g:i386) installed, and (checking) have no /lib/i386/security/ directory at all. /lib/security has very few files in it (only pam_dbus.so pam_gnome_keyring.so pam_mount.so pam_unix2.so), and they're all x86-64. All my other PAM modules are (as far as I know) in /lib/x86_64-linux-gnu/security/, but pam_smbpass.so is the only one throwing the "no such file" error. So... any idea what's going on here, and more importantly how to fix it? I also see consistently that this is a harmless message, but it bugs me...
