Re: pam_smbpass.so

[Christian Seiler]

On 02/18/2016 02:49 AM, Joe Pfeiffer wrote:
> Christian Seiler  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
> authoptionalpam_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

[Joe Pfeiffer]

Sven Hartge  writes:

> Joe Pfeiffer  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

[Joe Pfeiffer]

Christian Seiler  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
authoptionalpam_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

[Christian Seiler]

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

[Sven Hartge]

Joe Pfeiffer  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.