Hi, I got the code working with python3. Now I'm trying to get boto3 working with the provided pam-python3.so module. I tried both pip install boto3 and pip3 install boto3. But when I'm using the pam-python3.so module to execute my python file, I get the error ModuleNotFoundError: No module named 'boto3' What's the proper way to get third party python libraries working with the provide so module?
Hi, I got the code working with python3. Now I'm trying to get boto3 working with the provided pam-python3.so module. I tried both pip install boto3 and pip3 install boto3. But when I'm using the pam-python3.so module to execute my python file, I get the error ModuleNotFoundError: No module named 'boto3' What's the proper way to get third party python libraries working with the provide so module?
My latest additions (python 3.12 initialization stuff) are in the py3 branch of the git repo in https://anders_blomdell@git.code.sf.net/p/pam-python-py3/code
Thanks a lot for your work @rion. Works perfectly with my python pam module.
my fork of https://sourceforge.net/u/anders_blomdell/pam-python/ci/py3/tree/ is here https://github.com/castlabs/pam-python ChangeLog: 1. Added GIL locking to make is compatible with python-pam 2. Fixed crash/abort on invalid initialization of a doc string 3. Optimized module filename getter 4. Use macros macros provided by Python itself for object clearing and traversing 5. Removed parts explicitly related to already dead Python2 6. Added musl compatibility 7. other minor fixes and optimizations...
https://sourceforge.net/u/anders_blomdell/pam-python/ci/py3/tree/ worked well for me. The patch below unifies naming with other pam modules and make it compatible with alpine/musl. diff -r 58a247137c70 src/Makefile --- a/src/Makefile Wed Apr 07 09:36:11 2021 +0200 +++ b/src/Makefile Sat Mar 05 15:43:35 2022 +0300 @@ -17,7 +17,7 @@ install: install-lib install-lib: mkdir -p $(DESTDIR)$(LIBDIR) - cp build/lib.*/pam_python3.*.so $(DESTDIR)$(LIBDIR)/pam-python3.so + cp build/lib.*/pam_python3.*.so $(DESTDIR)$(LIBDIR)/pam_python3.so...
@rstuart Can we get a python3 release?
@rstuart Can we get a pyhton3 release?
Python 3.9 fixes
Thanks a lot for the patch. I had to create a symlink because of the make failing with "/usr/bin/ld: cannot find -lpython3.5" After creating the following symlink it compiled successful. ln -sf /usr/lib/x86_64-linux-gnu/libpython3.5m.so /usr/lib/x86_64-linux-gnu/libpython3.5.so Now my module is called on login. I'll report any issues while migrating my module to python3.
I was able to build 1.0.8 on Python 3.8 with "make" after applying the following patch. I haven't actually run this version to see that this patch is correct or that it even works, though, nor tried to get the test suites running: diff -ru /tmp/pam-python-1.0.8/src/pam_python.c /home/dan/chroot-cauldron/tmp/pam-python-1.0.8/src/pam_python.c --- /tmp/pam-python-1.0.8/src/pam_python.c 2020-11-10 01:58:10.000000000 -0800 +++ /home/dan/chroot-cauldron/tmp/pam-python-1.0.8/src/pam_python.c 2021-01-18...
Hi, is there any documentation how to build pam-python for python3?
@rstuart any luck on merging python3 functionality? Almost all of it is merged in 1.0.9. The only thing that isn't merged is actually building the .so, I think. That will have to wait until I have tests.
Release pam-python-1.0.8-1 - see ChangeLog.txt
Added tag pam-python-1.0.8-1 for changeset 9759f19e636c
@rstuart any luck on merging python3 functionality? I am trying to get this to work on Clear Linux which is on python3.8. I know some stuff changed about how to embed python. I couldn't get it to work. I don't know if this is the right solution, but I found that in setup.py distutils.sysconfig.get_config_var('INSTSONAME') returned libpython3.8.a. When trying to dlopen this in pam_python.c I am getting an error that libpython3.8.a: invalid ELF Header. I was wondering if libpython3.8.a is what you...
Module not able to open *.py file . Permission denied error
Hi all, I downloaded source from https://sourceforge.net/u/anders_blomdell/pam-python/ci/py3/tree/ and build it using make and make install on CentOS8.1. I defined a pam_sm_authenticate() function in seperate python file and try to called it inside /etc/pam.d/sshd file : auth required /lib/security/pam-python3.so /home/test.py use_first_pass But in /var/log/secure i am getting the following error Aug 20 15:26:17 localhost /home/test.py[7911]: Can not open module: Permission denied and my test.py...
Hi all, I downloaded source from https://sourceforge.net/u/anders_blomdell/pam-python/ci/py3/tree/ and build it using make and make install on CentOS8.1. I defined a pam_sm_authenticate() function in seperate python file and try to called it inside /etc/pam.d/sshd file : auth required /lib/security/pam-python3.so /home/test.py use_first_pass But in /var/log/secure i am getting the following error Aug 20 15:26:17 localhost /home/test.py[7911]: Can not open module: Permission denied and my test.py...
Hi all, I downloaded source from https://sourceforge.net/u/anders_blomdell/pam-python/ci/py3/tree/ and build it using make and make install on CentOS8.1. I defined a pam_sm_authenticate() function in seperate python file and try to called it inside /etc/pam.d/sshd file : auth required /lib/security/pam-python3.so /home/test.py use_first_pass But in /var/log/secure i am getting the following error Aug 20 15:26:17 localhost /home/test.py[7911]: Can not open module: Permission denied and my test.py...
Yes, the client code (python-pam) is needed for testing pam-python. Actually the naming is horrible
That software package is for PAM clients only. While this one here can be used to implment pam modules as well.
I'm just letting everybody know now the tests work, I've started intergrating all the changes for a new release.
Running tests without root
I'll look at it as part of the Python3 port.
To be explicit, this is a feature request for automatically using pam_wrapper for tests if autodetected or requested by the user.
Running tests without root
It probably was a huge, hard job :-)
Well, colour me impressed. You've done what I thought was a huge job hard. I'll try to have a closer look this weekend.
I used the Fedora PyPAM (thanks for sending that pointer OOB) and got some test failures. The first is a problem in the test harness itself: File "test.py", line 64, in assert_results assert len(expected_results) == len(results), (i, expected_results[len(results)]) UnboundLocalError: local variable 'i' referenced before assignment This is because "results" was empty so the for loop never got a chance to set i. After working around that, I realized my patch in the previous comment was insufficient...
FWIW, I tried the tree at https://sourceforge.net/u/anders_blomdell/pam-python/ci/f7a9e21bde726b8d68815d1e9572a0636d488a5c/tree/ with Python 3.8.2 and pam 1.3.1 on Linux x86_64 and it seems to work (it passes ctest, anyway). The install target doesn't work because it's missing the same glob in pam_python3.\*.so that the previous ln -s command has (it's missing in "cp build/lib.*/pam_python3.so $(DESTDIR)$(LIBDIR)). I couldn't find a PyPAM that works with Python 3 to try test.py but ctest passes,...
Redistributed without modification license question
Python environment
You're the hero! cat /tmp/python-path.dbg ['/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages'] And it works again. Many thanks!
I think you have tripped over the fix for CVE-2019-16729, which is a local root exploit caused manipulating Pythons import path. Try adding this to the top: import site site.main() That undoes some of the mitigations the fix did. Sorry - I haven't seen it trip someone up before, so it's taken me a while to catch on.
Yes OpenSSL is in /usr/lib/python2.7/dist-packages as expected for a package installed using the package manager. I built the container, and it's based on the ubiquitous default debian:buster image like this: FROM debian:buster and there's no python manipulation afterwards as far as I can tell. I won't bother you with support on how to build a decent container, but you may be able to shed a light on what may give pam_python.so a different python environment than the ssh env I'm logged into? I will...
OK, so one of the 1st group must contain the directory OpenSSL containing the Python OpenSSL module. Evidently none of the directories in the 2nd group does. Could you verify those two assumptions please. If both are true you will have to speak to the person who created the conatiner about why that is so, and what can be done to fix it.
root@sandbox1:~# python -c 'import sys; print sys.path' ['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages'] root@sandbox1:/opt/pam-websso# cat /tmp/python-path.dbg ['/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload']...
Lets go back to 1st principles. Run python -c 'import sys; print sys.path'. You will see a list of linux path's. Check that the OpenSSL directory exists in one of them. (Mine lives in /usr/lib/python2.7/dist-packages/OpenSSL/.) Now do the same thing from your pam-python module. Eg: add import sys; import sys; open("/tmp/python-path.dbg", "w").write(repr(sys.path)) somewhere before you do import OpenSSL will suffice. If that tells you nothing, reply with both results.
Lets go back to 1st principles. Run python -c 'import sys; print sys.path'. You will see a list of linux path's. Check that the OpenSSL directory exists in one of them. (Mine lives in /usr/lib/python2.7/dist-packages/OpenSSL/.) Now do the same thing from your pam-python module. Eg: add import sys; open("/tmp/python-path.dbg", "w").write(repr(sys.path)) somewhere before you do import OpenSSL will suffice. If that tells you nothing, reply with both results.
root's environment doesn't contain PYTHONPATH, nor any reference to python as far as I can tell.
Python environment
Is the PYTHONPATH defined in your clients environment? Off the top of my head that's the only thing that would effect how Python searchs for modules.
I was a bit rushed when reporting and forget to mention versions. We're testing on Debian Buster which ships libpam-python 1.0.6-1.1+deb10u1. The dependancy packages are all installed system-wide, as I don't/can't use a venv to run the pam module.
Python environment
ctest fails due to /usr/lib64/python3.7/lib-dynload/_heapq.cpython-37m-x86_64-linux-gnu.so being loaded by the call tracebackModule = PyImport_ImportModule("traceback"); forcibly unloading at end of cleanup_pamHandle by: static int dl_walk_heapq(struct dl_phdr_info* info, size_t size, void* data) { if (strstr(info->dlpi_name, "/_heapq.cpython") != 0) { void *handle = dlopen(info->dlpi_name, RTLD_NOW|RTLD_NOLOAD); if (handle) { while(dlclose(handle) == 0) { } } } return 0; } ... dl_iterate_phdr(dl_walk_heapq,...
Continued kenji's work in https://sourceforge.net/u/anders_blomdell/pam-python/ci/py3/tree/ now the python tests pass, ctest fails to unload the python libraries which might indicate memory leaks somewhere in the code.
Bump! I'd like to use this in the context of a python3 world, especially given python2.7's impending EOL. I'm wondering if there is an active ongoing effort to bring this library up to speed for python3 and/or when one could expect that to happen. Thanks!
Support passing args to the python script
The module arguments aren't passed via sys.argv. They can't be. The program your module is running in might be a python one, and in that case sys.argv will contain the command line arguments for the host program. Instead they are passed ain the manner the PAM Module Writers Guide perscribes: The argc and argv arguments are taken from the line appropriate to this module---that is, with the service_name matching that of the application---in the configuration file (see the Linux-PAM System Administrators'...
The module arguments aren't passed via sys.argv. They can't be. The program your module is running in might be a python one, and in that case sys.argv will contain the command line arguments for the host program. Instead they are passed ain the manner the PAM Module Writers Guide perscribes: The argc and argv arguments are taken from the line appropriate to this module---that is, with the service_name matching that of the application---in the configuration file (see the Linux-PAM System Administrators'...
Support passing args to the python script
Wow. I'm impressed. What are you using to drive the pam client side from Python?
I'm working on porting this to py3. The 11 of 12 unit tests pass. "run_xauthdata" is the only test that is failing.
Release pam-python-1.0.7-1 - see ChangeLog.txt
Added tag pam-python-1.0.7-1 for changeset 0247ab687b43
On Fedora python3-pam exists, and comes from: https://github.com/FirefighterBlu3/python-pam if I can be of any help, just say so...
I too encountered this issue while attempting to build the module on RHEL 7. Moving the Python.h up as described addressed the issue. version: 1.0.6
I too encountered this issue while attempting to build the module on RHEL 7. Moving the Python.h up as described addressed the issue.
Small update: pamh.PAM_PROMPT_ECHO_OFF works perfectly on openSUSE, but not on Debian/xUbuntu or CentOS. pamh.conversation() returns allways (except on openSUSE) allready typed SSH password. There is no way to rewrite it (get new string from user by asking in prompt). Is there any fix or workarond for that? Thank you
pamh.conversation returns wrong string
Thanks Russel for the update!
for that a patch can be found here: https://github.com/Ralnoc/pam-python/pull/3/files
I'm a Debian Developer, so I tend to do things on Debian's cycle. Debian is coming up for a release next year, so things will happen by then. The major thing is the port to Python 3. The major hold up is python-pam isn't available for Python 3, and python-pam is used for unit tests, and I'm anal about unit tests. So I either have to write it myself or find alternative. I have looked for an alternative, but haven't had much success so far.
Is the project dead?
_XOPEN_SOURCE redefined - include order
These are the patches I needed for Fedora 28 and 1.0.6, ie essentially the same fix as for 1.0.4 + small Makefile change to fix gcc8 cast error...
Run as root?
Should I release the python srouce code if it is called by pam-python? When you distribute you must acknowledge you are using pam-python so people can download it's source code. (A "licenses" web page in the applicace would suffice.) If you write a PAM module using pam-python you must release it's source code too, so everybody who uses your applicance can download it. The situation for a program (eg, "login" or "apache", or anything you write) calling a pam-python PAM module via PAM's API is a bit...
Redistributed without modification license question
Likewise, we are getting the below compilation error for pam-python-1.0.6 using sphinx v1.6.6 pam_python.c: In function ‘call_handler’: pam_python.c:2234:19: error: argument 1 null where non-null expected [-Werror=nonnull] if (dot != 0 || strcmp(dot, ".py") == 0) ^~~~~~~~~~~~~~~~~~ In file included from /usr/include/security/_pam_macros.h:13:0, from pam_python.c:33: /usr/include/string.h:136:12: note: in a call to function ‘strcmp’ declared here extern int strcmp (const char *_s1, const char *_s...
Hi Andres, Is this pach valid also for release 1.0.6? Thanks a lot, Evgeny
osx-igor
Added tag pam-python-1.0.6-1 for changeset ed98...
Release pam-python-1.0.6-1 - see ChangeLog.txt
Merge in OSX fixes