Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 145839 - net-mail/poppassd_ceti does not handle pam_ldap correctly
Summary: net-mail/poppassd_ceti does not handle pam_ldap correctly
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Matthew Ogilvie
Keywords: PATCH, PullRequest
Depends on:
Reported: 2006-09-01 05:30 UTC by Warren Howard
Modified: 2021-01-18 23:41 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---

patch to poppassd.c to add pam_ldap support (poppassd.c-patch,4.72 KB, patch)
2006-09-01 05:38 UTC, Warren Howard
Details | Diff
poppassd.c-1.patch (poppassd.c-1.patch,1.67 KB, patch)
2007-01-20 16:31 UTC, Warren Howard
Details | Diff
poppassd.c-2.patch (poppassd.c-2.patch,1.08 KB, patch)
2007-01-20 16:32 UTC, Warren Howard
Details | Diff
poppassd.c-3.patch (poppassd.c-3.patch,1.94 KB, patch)
2007-01-20 16:34 UTC, Warren Howard
Details | Diff
poppassd.c-4.patch (poppassd.c-4.patch,2.69 KB, patch)
2007-01-20 16:35 UTC, Warren Howard
Details | Diff
poppassd.c-5.patch (poppassd.c-5.patch,2.43 KB, patch)
2007-01-20 16:36 UTC, Warren Howard
Details | Diff
1.8.9 ebuild (preliminary) (poppassd_ceti-1.8.9.ebuild,1.58 KB, text/plain)
2020-11-16 00:54 UTC, Matthew Ogilvie

Note You need to log in before you can comment on or make changes to this bug.
Description Warren Howard 2006-09-01 05:30:02 UTC
popassd-ceti ( and 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.


Comment 1 Warren Howard 2006-09-01 05:38:01 UTC
Created attachment 95639 [details, diff]
patch to poppassd.c to add pam_ldap support

attaching the patch.
Comment 2 Marcus D. Hanwell (RETIRED) gentoo-dev 2006-09-28 03:24:51 UTC
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.
Comment 3 Warren Howard 2006-09-28 05:03:06 UTC

Okay, please let me know if there is anything required from my side.


Comment 4 Marcus D. Hanwell (RETIRED) gentoo-dev 2006-11-04 03:38:05 UTC
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.
Comment 5 Warren Howard 2006-11-05 20:25:15 UTC

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.


Comment 6 Warren Howard 2007-01-20 16:29:32 UTC

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 (, 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.


Comment 7 Warren Howard 2007-01-20 16:31:22 UTC
Created attachment 107552 [details, diff]

poppassd.c-1.patch  =>
	1. Many unused variables have been removed
	2. Indentation has been made proper
Comment 8 Warren Howard 2007-01-20 16:32:47 UTC
Created attachment 107554 [details, diff]

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
Comment 9 Warren Howard 2007-01-20 16:34:04 UTC
Created attachment 107556 [details, diff]

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.
Comment 10 Warren Howard 2007-01-20 16:35:16 UTC
Created attachment 107557 [details, diff]

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.
Comment 11 Warren Howard 2007-01-20 16:36:32 UTC
Created attachment 107559 [details, diff]

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.
Comment 12 Warren Howard 2007-01-20 16:40:58 UTC
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.


Comment 13 Marcus D. Hanwell (RETIRED) gentoo-dev 2009-08-01 23:35:27 UTC
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.
Comment 14 Matthew Ogilvie 2019-11-24 04:17:26 UTC
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".


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 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.
Comment 15 Matthew Ogilvie 2020-11-16 00:54:48 UTC
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

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

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 <>
Comment 16 Larry the Git Cow gentoo-dev 2021-01-18 09:28:18 UTC
The bug has been referenced in the following commit(s):

commit 8186e14efd61d97cdac690d3c1d8a637eb70b0a7
Author:     Matthew Ogilvie <>
AuthorDate: 2020-12-23 20:16:15 +0000
Commit:     Joonas Niilola <>
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.
    Signed-off-by: Matthew Ogilvie <>
    Signed-off-by: Joonas Niilola <>

 net-mail/poppassd_ceti/Manifest                   |  1 +
 net-mail/poppassd_ceti/poppassd_ceti-1.8.9.ebuild | 65 +++++++++++++++++++++++
 2 files changed, 66 insertions(+)
Comment 17 Matthew Ogilvie 2021-01-18 23:41:08 UTC
@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

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.