7

I am configuring yubico-pam to enable passwordless sudo access using challenge-response from a Yubikey. The following works:

# /etc/pam.d/sudo
auth       sufficient     pam_yubico.so mode=challenge-response
auth       required       pam_opendirectory.so
account    required       pam_permit.so
password   required       pam_deny.so
session    required       pam_permit.so

unless the pam_yubico.so module is missing, uninstalled, or corrupted, in which case one is told:

$ sudo su -
sudo: unable to initialize PAM: No such file or directory

Is it possible to tell PAM to ignore a module that is missing, rather than simply returning immediately and prevent PAM from continuing to evaluate the stack?

vvvvv
  • 174
  • 10
CodeGnome
  • 285
  • 2
  • 9

1 Answers1

0

In the extended syntax (see pam.conf(5)), it's possible to define a custom behavior for when the dlopen() call fails by defining a behavior for the open_err error code. That said, sufficient should already be accomplishing this for you. Here's the equivalent extended syntax from that same manpage:

    sufficient
      [success=done new_authtok_reqd=done default=ignore]

See that default=ignore at the end?

   The last of these, default, implies ´all valueN´s not mentioned
   explicitly. Note, the full list of PAM errors is available in
   /usr/include/security/_pam_types.h. 

In other words, default=ignore is equivalent to open_err=ignore. Unless PAM is behaving in a way that is not documented here, this would suggest that the failure is occurring further down the stack.

Just to eliminate any doubt, here's the definition of PAM_OPEN_ERR from the headers:

#define PAM_OPEN_ERR 1          /* dlopen() failure when dynamically */
                                /* loading a service module */
Andrew B
  • 32,588
  • 12
  • 93
  • 131
  • On OS X Yosemite, the stack dies with `sufficient` if pam_yubico.so isn't available, such as when MacPorts or Homebrew implode. So, it may certainly be undocumented behavior, or one of the defined exceptions isn't being caught. If you have a suggestion about how to debug this, I'd be glad to give it a shot if there's a way to catch the actual error. Hint: appending debug doesn't accomplish that; I've tried that already without useful results. – CodeGnome Apr 03 '15 at 04:30
  • The only thing I can think of recommending is defining an explicit `auth [success=done new_authtok_reqd=done open_err=ignore default=ignore] pam_yubico.so mode=challenge-response` to see if the behavior differs in an undocumented way. `open_err` by all appearances exists to allow the type of behavior you're looking for. – Andrew B Apr 03 '15 at 04:48
  • Actually, I take that back: all of the documentation I just quoted only applies to Linux-PAM. As you mentioned in the comments, you're using OS X, which uses OpenPAM instead. A quick scan of the [raw pam.conf manual page](http://www.openpam.org/browser/openpam/trunk/doc/man/pam.conf.5) for OpenPAM seems to suggest that the extended syntax may not be supported at all here. Unfortunately I think you're on your own. – Andrew B Apr 03 '15 at 05:04