Upgrade the bits and then uninstall fails:

Traceback (most recent call last):
File "/sbin/ipsilon-server-install", line 460, in
uninstall(fplugins, opts)
File "/sbin/ipsilon-server-install", line 284, in uninstall
if plugin.unconfigure(args, plugin_changes) == False:
File "/usr/lib/python2.7/site-packages/ipsilon/login/authpam.py", line 164, in unconfigure
installed_files = changes['installed_files']
KeyError: 'installed_files'

Authentication is failing but I have yet been able to identify why.

Just pushed a new commit that wraps the

installed_files['installed_files']

in a try/except block that catches the key error and returns earl.

I'd have preferred install_files.get('installed_files', [])

And I still can't authenticate with the new pam service for some reason I can't deduce.

I redid the commit per your preference.

I can't explain the auth failure either. I have a tiny C program that calls pam and if I pass it exactly the same username, password and service name that Ipsilon is seeing (I logged those values) it succeeds. The pam.py module can be invoked as a program, if I pass it the exact same parameters it also succeeds. It appears to only not work when called from Apache. I put SELinux in permissive mode, but it didn't help. So I'm befuddled as well. When was the last time we confirmed pam was working in Ipsilon? I'm not seeing anything in my patch that would explain the auth failure, both a C based pam test and a Python based pam test using the ipsilon service name and same username and password works. Go figure.

As a data point I installed another version of Ipsilon without my pam patch, it also fails to authenticate. At this point I'm guessing it's something in the way the python pam is interacting when executed from inside Apache. I think to get further we'll have to run Ipsilon under GDB and see what the PAM code is doing.

I spent a day trying to debug this but failed to find a root cause, here is what I know at this point:

The user is local with an entry in /etc/passwd and /etc/shadow.

SELinux is in permissive mode.

Running a pam test program with the exact same parameters works.

I built a special version of pam with debug logging, the log goes to /var/run/pam-debug.log which must be manually created and be chmod a+rw.

The failure occurs when running the suid helper program /usr/sbin/unix_chkpwd which pam_unix invokes via fork/execv.

unix_chkpwd calls get_account_info() passing the username, which then invokes pam_modutil_getspnam() which due to macros is really just a call to getspnam().

getspnam() is a nss switch function. The nssswitch config for both passwd and shadow is "files sss", so it should hit the local file entry first.

I set a breakpoint for getspname and it broke at ../nss/getXXbyYY.c:102. I lost the trail there. It returns null, and everything is a cascading set of errors after that.

So it appears that getspnam when called from the setuid unix_chkpwd succeeds when invoked from a standalone pam test program but fails when called from Ipsilon. At this point I still do not know why, but that is as much as I can do for today.

Sorry to hear you spent a day on trying the pam module with a local account, as that is a known fail.

pam_unix uses a helper that allows you to only ever perform a password change from a non-root process, and, of course, only for the calling user. Authentication is not allowed from non-root processes.

The ipsilon pam module works with pam_sss though.

I figured out why it was failing for me: the pam configuration file ipsilon is only created if the pam auth module is enabled.

These are not linked together as the form module relies indirectly on pam for authentication as well. I copied remote to ipsilon and authentication started working for me.

New commit has been pushed for review.

authpam no longer installs and uninstalls the ipsilon pam service file because the ipsilon pam service file is utilized by both the pam and form login managers. Ipsilon currently has no mechanism to express shared dependencies. So instead the ipsilon pam service file is installed by the base RPM subpackage, thus it's always available irregardless of the pam or form login manager installation/configuration. The consensus is that a unreferenced pam service file is benign.

ACK

Merged