popassd-ceti (http://packages.gentoo.org/ebuilds/?poppassd_ceti-1.8.5-r1 and http://www.echelon.pl/pubs/poppassd.php) has some PAM support. However that does not include pam_ldap support. In poppassd.c there is one function that manages the change password "conversation" with pam and it was passing a new password to pam_ldap when pam_ldap was expecting an old password. Anyway a C programming colleague at work made a patch for poppassd.c to get it working with pam_ldap. I've sent the patch to the author of the program, but not heard anything back so I have no idea if the patch will be incorporated into the main program. I find having pam_ldap support in poppassd very useful and others might too so I'm submitting it here. I imagine that ebuild for poppassd could be updated so that the patch would be installed when the "ldap" use flag was present. Regards, Warren.
Created attachment 95639 [details, diff] patch to poppassd.c to add pam_ldap support attaching the patch.
Sorry - only just spotted this bug as I have been really busy. I will look at integrating this shortly - I cannot test as I don't have an ldap server set up but so long as it appears to still function with normal set ups too (many with ldap USE flag don't use it for auth) then I can't see a problem adding it.
Hi, Okay, please let me know if there is anything required from my side. Thanks, Warren.
Sorry this has slipped by the wayside... There are quite a few changes made to the code, and so I am going to need to do some testing. Have you managed to submit this upstream? I am trying to appreciate all the consequences of the change but am not a pam expert. Ideally this would be applied globally if it is in fact a safe change - I can see some of the changes you have made appear to be purely cosmetic too which obscures the real changes a little. Not sure if the upstream maintainer is still active.
Hi, Yes I did try contacting upstream but so far no reply. I'll get some documentation put together for the patch, that should help in working out what the next step should be. Regards, Warren.
Hi, I've got some documentation from the friend who made the changes to poppassd for me. The documentation is below and the single patch that was supplied previously has been split into five smaller patches that (hopefully) will make the changes clearer. The are patches for poppassd.c (http://echelon.pl/pubs/poppassd-1.8.5.tar.gz), use patch -p0 for all patches. I think an LDAP use flag could be included for poppassd which would apply the patches, thus providing pam_ldap support. Regards, Warren.
Created attachment 107552 [details, diff] poppassd.c-1.patch poppassd.c-1.patch => 1. Many unused variables have been removed 2. Indentation has been made proper
Created attachment 107554 [details, diff] poppassd.c-2.patch poppassd.c-2.patch => 1. Bug removal - improperly placed malloc() 2. "500 PAM error" must always do exit(1) 3. Bug removal - "pw == NULL" must be checked first
Created attachment 107556 [details, diff] poppassd.c-3.patch poppassd.c-3.patch => 1. getstate() checks the PAM message to find out the current state 2. pop_state is not required since getstate() works better Note 1 : Patches 1-3 above provide the "core" of the new LDAP functionality for poppassd. Previously poppassd was blindly assigning pop_state with various values without considering what the PAM messages really are. Now getstate() tries to find out the state based on the PAM message, thus providing the support for pam_ldap.
Created attachment 107557 [details, diff] poppassd.c-4.patch poppassd.c-4.patch => 1. uses getopt() to accept additional PAM messages as program arguments. 2. pamstrings[] stores the additional PAM messages provided as arguments. 3. setstrings() adds the additional PAM messages to pamstrings[] 4. showusage() shows the help when we pass 'h' as argument to poppassd. Notes : * Patch 4 above introduces new command line options for passing customised messages to poppassd. * Each and every PAM message will first be compared with the list of messages that prompt for the "old" password before being compared with the list of messages that prompt for the "new" password. * Within each "old" or "new" PAM messages list the additional (supplied at the command line) PAM messages are compared before the default messages. * The purpose of the command line option is to pass additional PAM messages to poppassd so that poppassd will work (without changing the code and recompiling) with customisations to the password prompts for example the "type" option provided by cracklib.
Created attachment 107559 [details, diff] poppassd.c-5.patch poppassd.c-5.patch => 1. uses the global variables oldstr, newstr to store default PAM messages. 2. pamstrings[] now stores the default PAM messages too(but in the end) 3. simplified the getstate() function. Notes : * Patch 5 cleans up the code a little by storing both the default PAM messages and the additional PAM messages (provided by on the command line) in a single location (pamstrings[] array). * The default messages that prompt for the "old password" can be found in the global array oldstr[] and the default messages that prompt for the "new password" can be found in the global array newstr[]. If required PAM messages can be added, removed or changed within the global arrays oldstr[] and newstr[] before compilation.
Applying the patches and compiling for me works like so : # ls COPYING README poppassd.c-1.patch poppassd.c-3.patch poppassd.c-5.patch Makefile poppassd.c poppassd.c-2.patch poppassd.c-4.patch # patch -p0 -i poppassd.c-1.patch patching file poppassd.c # patch -p0 -i poppassd.c-2.patch patching file poppassd.c # patch -p0 -i poppassd.c-3.patch patching file poppassd.c # patch -p0 -i poppassd.c-4.patch patching file poppassd.c # patch -p0 -i poppassd.c-5.patch patching file poppassd.c # make gcc -O2 poppassd.c -o poppassd -lpam -ldl # ls COPYING README poppassd.c poppassd.c-2.patch poppassd.c-4.patch Makefile poppassd poppassd.c-1.patch poppassd.c-3.patch poppassd.c-5.patch An example of using the new command line switch for passing additional pam messages is : ./poppassd -n "New CompanyName password: " -n "Retype new CompanyName password: " It's working for me. Regards, Warren.
Sorry Warren, this totally slipped through the cracks. Are you still using this package? Is there any sign of an upstream? I can make a rev bump, but your patches are effectively a fork with lots of updates to the code. So a new release/version would be nice in many ways. Does this work with current Gentoo? I don't have ldap set up here to test. I could apply these patches conditionally on an ldap use, but would appreciate confirmation they still work.
Does anyone still care about this? Given the lack of any activity since the ping from a previous maintainer more than 10 years ago, I'm inclined to close this as "wont fix". Also: I have most of the same concerns expressed in comment 4 (13 years ago) and comment 13. Splitting it up helped a bit, but it still seems like a really intrusive collection of changes to accept without going through upstream first, along with being reviewed by people who know PAM much better than I do. I briefly looked at possibly using LDAP some years ago, and from what I remember just setting up a minimal test case would be rather involved. Upstream has moved to https://github.com/kravietz/poppassd-ceti if someone wants to pursue this. I think some of the basic cleanup (patches 1 and 2) has already been incorporated (possibly independently?) into 1.8.7. Matching prompt strings that are intended for users seems a little questionable. Is there no better way? It seems especially questionable to match them against strings specified on the command line - could there be cases where the command line might be under an attacker's control somehow, and they could purposely confuse poppassd in some way that might open some kind of security risk, particularly if some other mechanism besides [x]inetd port 106 is used to invoke it? Maybe a protected config file in /etc would be better. Or I kind of suspect it might be better to make a completely separate tool or fork ("poppassd_ldap"?), and maybe it should bypass PAM and talk to the underlying LDAP databases directly? ---- I suppose that even without LDAP, PAM could possibly be configured in an odd way that poppassd isn't expecting, and might pose a risk. Perhaps involving multi-factor authentication or something. I don't know enough about PAM to be sure, but hopefully anyone with an odd configuration would test things and either abandon poppassd_ceti in favor of something else, or at least get it fixed before enabling it.
Created attachment 671578 [details] 1.8.9 ebuild (preliminary) Here is a preliminary attempt at an updated ebuild for version 1.8.9, which claims to support LDAP. It compiles and installs, but I call it "preliminary" for several reasons: 1. I haven't tested it at all yet (maybe this week sometime...). - I probably won't ever try to test its reputed support for LDAP. I don't want to take the time to figure out how to set up enough of a minimal LDAP environment, when I'm not using it myself. I'll probably rely on reports from others. 2. It has been reworked to build using cmake, and I have almost zero knowledge of cmake. - Is the "CMAKE_IN_SOURCE_BUILD=1" near the top a reasonable thing to do, or is there a better way? Without it, it gets a compiler error when it #include "config.h" . 3. I've updated it to install the two systemd unit files that now come with it, as an alternative to xinetd. However: - I have no systemd-based systems to actually test them on. - Some of the comments include "@" signs in unit file names, but the actual installed files don't? What does the "@" sign mean? - The files seem to expect installation under /etc/systemd but most systemd unit files on gentoo (including these) seem to end up under /lib/systemd. I think this just works (default files vs customized, or something), but I'm not sure. - Hopefully the port and service are disabled by default. If not, that could probably be considered a security hole. - The latest (unreleased) documentation on github claims that it defaults to binding to localhost only, but that isn't obvious from the unit files themselves. - It might be good to mention the systemd option in the README.gentoo text in the ebuild, in addition to xinetd and sudo. But I'm not sure exactly what it should say. 4. It also has it's own different /etc/pam.d/poppassd file that we could potentially use, but I don't really understand the differences. - Since I don't really understand PAM or the different versions of the config file, I'm inclined to continue using "pamd_mimic_system" from pam.eclass instead. (Particularly since after the most recent release there has been additional rewrites and churn in the PAM configuration file.) 5. It is (probably?) good that this ebuild uses an entirely custom src_install(), without using make install or cmake or anything similar: - If I interpret lines like 'install(CODE "execute_process' [...] ')' in CMakeLists.txt correctly, it looks like the default "make install" would actually start the service automatically? That sure sounds unexpected and potentially risky... - See also bullets 2 and 4, and possibly also 3. ---- Can anyone provide any insight into whether this ebuild is handling systemd config, PAM config, cmake stuff, actually works with LDAP, etc in reasonable ways? I would like some feedback before trying to actually get this into gentoo. I'm only vaguely aware of the details of any of these. (That's a lot of big things to carefully study in order to fully understand such a simple program...) Signed-off-by: Matthew Ogilvie <mmogilvi+gnto@zoho.com>
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8186e14efd61d97cdac690d3c1d8a637eb70b0a7 commit 8186e14efd61d97cdac690d3c1d8a637eb70b0a7 Author: Matthew Ogilvie <mmogilvi+gnto@zoho.com> AuthorDate: 2020-12-23 20:16:15 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2021-01-18 09:27:37 +0000 net-mail/poppassd_ceti: bump 1.8.9 This works properly in my existing sudo-based installation. However, upstream (and this ebuild) has added new LDAP support and systemd unit files, and I don't have an environment to test either. Bug: https://bugs.gentoo.org/145839 Signed-off-by: Matthew Ogilvie <mmogilvi+gnto@zoho.com> Closes: https://github.com/gentoo/gentoo/pull/18795 Signed-off-by: Joonas Niilola <juippis@gentoo.org> net-mail/poppassd_ceti/Manifest | 1 + net-mail/poppassd_ceti/poppassd_ceti-1.8.9.ebuild | 65 +++++++++++++++++++++++ 2 files changed, 66 insertions(+)
@juippis: Thanks for merging a version of my pull request with a version of this ebuild. Regarding juippis' comment about tests in the pull request, and associated tweaks to the ebuild: In the merged version of the ebuild, I agree that setting "RESTRICT=test" is a a good idea, although the commented reason ("Tests seem to hang") is only scratching the surface of a much bigger issue with the design of the upstream tests. The main problem is that the upstream tests are trying to create and modify a "test1" user account on the system it is being built on, which seems like a clear violation of the policy of strictly forbidding tests from any attempts to use (or especially modify) "production servers running on the host", as outlined in the "Tests that require network or service access" section of https://devmanual.gentoo.org/ebuild-writing/functions/src_test/index.html The upstream tests use sudo to get root access to create and modify a "test1" user account, and I suspect it hangs because sudo is interactively asking for the current user's (portage's?) password to proceed. (Although I haven't' actually confirmed this suspicion.) Technically this could be "fixed" by adding an appropriate "NOPASSWD:" line to the the /etc/sudoers file specifically to allow these tests to run, but I don't think we actually want to allow automated tests to modify real users at all. The upstream tests are very minimal. It would only test against PAM-using-LDAP (this issue) if PAM has already been separately configured to use LDAP - something I don't really know much about. Searching around, I did stumble on a fairly new package called sys-libs/pam_wrapper described as "A tool to test PAM applications and PAM modules". I'm just guessing here, but perhaps something like it could be leveraged to test poppassd_ceti without modifying real user accounts or PAM configurations. But I kind of doubt I'll ever have the time to dig into how to set up tests to use it myself. My testing was manually done based on a custom web app that uses poppassd_ceti on one of the machines I maintain. I suspect such improved tests would not actually use sudo (edit sudo out of scripts, wrap/stub it out, or similar), but in the meantime, if someone actually wants to run the poppassd_ceti test suite "semi-manually", perhaps the conditional dependency on sudo (IUSE=test) is reasonable? (I'm on the fence...) In the meantime, "RESTRICT=test" (as already specified) is probably the best option.
